#728 closed defect (wontfix)
xrandr reports screen dimensions as 0mm x 0mm
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 2.0 |
Component: | server | Version: | trunk |
Keywords: | dummy randr x11 | Cc: | rektide@… |
Description
$ xrandr xrandr: Failed to get size of gamma for output default Screen 0: minimum 320 x 175, current 2560 x 1600, maximum 8192 x 4096 default connected 2560x1600+0+0 0mm x 0mm
Attachments (2)
Change History (11)
comment:1 Changed 6 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → assigned |
Changed 6 years ago by
Attachment: | dummy_driver.c added |
---|
modified dummy driver which dumps a lot more information about internal data structures
comment:2 Changed 6 years ago by
Following the work on #349, down the rabbit hole we go..
XRRGetOutputInfo
is from libXRandR, it gets the mm dimensions from the xRRGetOutputInfoReply
response to a RRGetOutputInfo
X11 server call (subpixelOrder
is in there too).
The server populates xRRGetOutputInfoReply
from the RROutputPtr
it gets using the VERIFY_RR_OUTPUT
macro..
RROutputPtr
is a pointer to RROutputRec
(aka _rrOutput
) which has more or less the same data in it, including mm and subpixel order.
The only place the server creates RROutputRec
is in RROutputCreate
.
But when I dump the outputs in the dummy driver, there aren't any! And if I add one using:
output = RROutputCreate(pScrn->pScreen, "default", 7, NULL); output->mmWidth = pScrn->pScreen->mmWidth; output->mmHeight = pScrn->pScreen->mmHeight;
It shows the output (and more warnings about missing modes for the output):
dummy connected 2560x1600+0+0 (0x55) normal (normal) 677mm x 423mm
but the mm stays at 0...
In the end, I think the "default" output we see is a virtual one. Created where?
I give up. For now.
Changed 6 years ago by
Attachment: | dummy_driver.2.c added |
---|
hacked driver with lots of unsuccessful changes to try to figure out what we need to do
comment:4 Changed 5 years ago by
Keywords: | dummy randr x11 added |
---|---|
Milestone: | 0.16 → 1.0 |
No movement on this upstream, re-scheduling.
comment:7 Changed 4 years ago by
Cc: | rektide@… added |
---|
comment:8 Changed 4 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Best to deal with this in #56
comment:9 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/728
The code that prints this is is in xrandr.c
With:
And we have in
get_outputs()
the core of it, which populates theall_outputs
global, a linked list (seeall_outputs_tail
) of all outputs:noutput
is set incrtc_add_output
:Which is called from
set_crtcs
:So, it looks like we need to ensure
XRROutputInfo
is populated correctly. Here it is:It is interesting to see
subpixel_order
is in there too. Maybe we should add another window property to allow us to change this on the fly (see #559) as there is bound to be software out there that does not use the standard way of figuring out the pixel order and will use hardware calls instead.We may also want to deal with the gamma warning, which comes from:
This should be simple enough:
Which is returned by:
I don't think we want to do any gamma correction on the server. The client will do it already when rendering the output.
Would be easy to add if we need it.
Excellent overview: X Events