Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Feature request: mbox: Supported mode list or EDID retrieval #108

Closed
swarren opened this Issue Oct 21, 2012 · 9 comments

Comments

Projects
None yet
3 participants

swarren commented Oct 21, 2012

The property mailbox interface provides a good set of messages for configuring the display. However, there is no way to either query the list of supported modes nor the EDID. This would be useful so that software can automatically configure the display to some supported mode.

I have found that I can call "Get physical (display) width/height" (0x00040003) to determine what resolution the firmware configured, which does match the display's preferred mode on the 2 displays I tested with, so all is not lost. However, there is still no way to know what other modes could be supported.

One alternative I can see is to directly use I2C2 to read the EDID. However, this would presumably interfere with the firmware's use of that device for its own EDID accesses, plus this wouldn't work if the SDTV output was in use rather than HDMI. Oh, and I don't think the I2C2 base address is documented in the peripherals PDF either.

Contributor

popcornmix commented Oct 21, 2012

Using I2C would interfere with GPU.
Note that the resolution set through the mailbox doesn't affect the HDMI mode, only the size of the framebuffer (which is then scaled to fit HDMI resolution minus overscan).
The edid can be read through the tvservice (e.g. tvservice -d edid.dat). tvservice can also query current sdtv/hdmi mode and set specific hdmi modes.

swarren commented Oct 21, 2012

Doesn't the mailbox message "set physical (display) width/height" affect the signal sent to the monitor, and message "set virtual (buffer) width/height" set the buffer size, with the GPU scaling between the two during scanout? If that isn't the case, what is the difference between the two messages, and what's the purpose of "set physical"?

Running tvservice from U-Boot or a mainline kernel which doesn't have the Broadcom drivers yet would be "problematic". I was looking for a defined public method of acquiring the EDID or mode list in order to implement U-Boot or mainline kernel. I have plenty of other ways of retrieving the EDID one-time for inspection.

Contributor

popcornmix commented Oct 21, 2012

No, virtual buffer size defines the memory size allocated. physical size defines the dimensions of the source image within that buffer (to allow for panning).
The resize occurs from physical size to diplay size (i.e. resolution from HDMI or composite) minus overscan.

swarren commented Oct 23, 2012

Oh, OK. I updated the property mailbox wiki to make this clear. I guess there's no way to alter the video signal resolution at the moment then, so there's little point being able to query the EDID or supported resolutions. That of course leads me to request these features via the property mailbox interface:-)

Contributor

popcornmix commented Oct 23, 2012

The tvservice api is quite large, so this will be duplicating work. Obviously if this makes HDMI control more standard and accessable for existing linux apps, then it's worthwhile.

So what features do you need?
What will be called from kernel drivers?
How will it be exposed/controlled?

swarren commented Oct 25, 2012

FYI, I took a look at the vchiq code and tvservice user-space code. It's much more ... complex ... than the property mailbox interface. It's certainly not something I'd expect to see make it into U-Boot, and most likely not the upstream Linux kernel. That said, I wonder if any RPC-style (vchiq /or/ property mailbox) code would ever make it into the upstream kernel.

(If the VC implemented a full X server and just talked to the ARM core using a virtual Ethernet device, over which standard Xlib, GLX, ... protocols ran, that'd be a lot easier to get upstreamed... Negative: A KMS driver would be hard that way. Positive: At least we could use the standard Xlib/GL user-space libraries to talk to the VC though.)

So the idea behind this issue was to allow creation of a Linux (or U-Boot) "driver" that could control the RPI's display. Typically this would be a basic DRM/KMS driver probably exposing also a legacy /dev/fb interface. Aside from what the property mailbox supports today, such a driver would normally allow the set of supportable resolutions to be queried, and one selected and set. The modesetting X driver could run on top of that to provide a simple unaccelerated X server. Beyond this, providing a full implementation of XRandR would require more features be available. Access to acceleration functions would be desirable beyond that.

If its guaranteed that the firmware will always initialize the physical buffer size to the display's preferred mode (or whatever the user explicitly asked for in config.txt), I suspect the simplest thing to do here is just to close this issue as wont-fix; U-Boot and possibly the kernel can just query the current physical buffer size and not change it.

Contributor

popcornmix commented Oct 25, 2012

From boot the firmware will set a default mode based on edid (possibly overidden by config.txt), so just querying should be sufficient for now.

If you are interested in producing a DRM/KMS driver and specify the mailbox messages you would like implemented, then that may be possible.

Laksen commented Nov 4, 2012

If we only look at the HDMI interface, since the firmware can read the EDID on boot, would it then not be possible to have a message which reread the EDID of the connected monitor and transmit the entire EDID back?

This, combined with a message to get/set a mode given the normal information(porches, etc) or hdmi mode number would be pretty awesome.

Contributor

popcornmix commented Dec 27, 2012

I've added a "Get EDID block" message to mailbox interface. Available in latest firmware.

@popcornmix popcornmix closed this Jan 24, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment