-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add new resolutions to Xdummy on the fly - dummy driver needs randr support added? #56
Comments
2011-12-06 19:32:09: totaam uploaded file
|
After asking xorg-devel, it would seem that the dummy driver does not support randr - or at least not fully. The patch above attempts to replicate xrandr's command line functionality and even includes its own modeline calculator, so from xpra's side it is pretty much ready. |
Not heard back, and less critical now that the default config contains many of the typical resolutions found on desktops and even android devices. |
2012-09-21 05:20:43: onlyjob uploaded file
|
Closed #186 (duplicate - some info there) |
Asked xorg dev again: RFC: dummy driver RandR improvements? Some other links: |
Forgot to update this ticket:
|
NNicolas Boichat has just posted X11 patches to do exactly this!: PATCH dummy: Add support for custom resolutions (RandR 1.2) Maybe this will fix #728 |
Looks like the discussion of what to do for randr 1.2 support is ongoing: Cleanups and RandR 1.2 support, with different implementations suggested. And so this will have to wait until this gets merged in one form or another, and maybe we only have to package it then which would be great (assuming that the new code can be built against older servers that is...) |
Maybe this can help us: RandR 1.5 Brings Monitor Objects & Tile Support For X.Org |
Re-post: xvfb: add randr support (v2) I think we should update the dummy driver with the same changes. |
In one of the responses to the patch above: [http://lists.x.org/archives/xorg-devel/2015-June/046666.html] links to: PATCH xf86-video-dummy 0/6: Cleanups and RandR 1.2 support - which is a better approach IMO. |
2015-09-16 12:49:47: antoine uploaded file
|
2015-09-16 12:50:10: antoine uploaded file
|
2015-09-16 12:50:30: antoine uploaded file
|
2015-09-16 12:50:47: antoine uploaded file
|
2015-09-16 12:51:19: antoine uploaded file
|
2015-09-16 12:51:34: antoine uploaded file
|
just tried the patch series above and hit a snag: my xorg-devel reply |
See also: MST monitors and the proposal for RandR 1.5 which would have the concept of "monitors" (without requiring us to have virtual CRTCs attached to them apparently) |
The randr v2 patch has been merged: Commit: 3d68d1f26709ecb5ce22a9baa0d3d8162574ed6a. So either we figure out how to use the same code in Xdummy, or we switch back to Xvfb with newer versions? |
We're not alone in needing this: xf86-video-dummy: resize to exact resolution from Chrome Remote Desktop developer Erik Jensen. |
I don't have time for this, new links:
|
2016-09-23 06:59:00: antoine uploaded file
|
Recent discussion: remove dead code in dummy driver: In 2014 I had also modified the dummy driver while working with Teradici Corporation to support not only arbitrary pixel dimensions, but also multiple monitors. The latter feature might not make sense to some folks, but if you have a server-side Xserver mapped to a hardware thin client sitting across a network, which has multiple physical monitors attached, you want the Xserver to be configured in the exact same manner as the tin client. Even though there is just a virtual framebuffer in main memory, X applications need to know the number/size/location of monitors so that toolbars are placed properly, windows are fullscreen'ed properly, etc. And when the user moves from one hardware thin client to another, which may have a different monitor configuration, the Xserver session needs to change to that configuration. |
This will also make #1008 redundant. |
Raising again. This is the commit that added randr to Xvfb: vfb: add randr support (v2) |
Done for Xvfb in r16994.
Still TODO:
|
r16996: improvements, client fixes (inc html5) |
this has been the case for a long time
(this happens with multiple monitors of the same size)
* use a new capability rather than overloading the old one once more, * change the monitor data format from #56 to match the GTK names more closely (easier), * apply client desktop-scaling to monitor data
FWIW: Don't remove an existing monitor from an output if another monitor is added changes how the dummy driver handles randr calls. It doesn't seem to have broken anything! |
Instead of finding the nearest match, we should just add the modeline, assign it to the output then select it.
This would allow us to match the client's screen size exactly.
(somewhat blocked by #10)
The text was updated successfully, but these errors were encountered: