Post by Perry E. Metzger via shifter-usersOn Wed, 12 Sep 2018 08:43:56 -0400 "Perry E. Metzger via
Post by Perry E. Metzger via shifter-usersPost by Antoine Martin via shifter-usersPost by Perry E. Metzger via shifter-usersMy impression from reading old trouble tickets is that I need to
install a patched version of the Xdummy stuff but I'm not
exactly sure. What do I need to do, roughly? (I searched and
couldn't really find exact instructions...)
http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy
BTW, thanks!
Post by Perry E. Metzger via shifter-usersDo I just patch xserver-xorg-video-dummy with what's in patches/ ?
I presume I can use the Ubuntu source package to do this?
That worked for me. I'm still not quite sure what the _correct_ dpi
for my setup is (how can I figure that out?)
In theory, xpra will figure out the DPI in use by the client (taken from
the command line option if it is specified, then trying
user-configurable places like Xft/DPI, and falling back to a calculated
"hardware DPI" if nothing else is available), it then tells the server
to apply this DPI value to the virtual framebuffer.
With the patched dummy driver, the virtual framebuffer used by the
server should have the exact virtual "hardware" geometry requested by
the client.
Applications started after this framebuffer resizing event should see
the correct screen resolution no matter how they look it up.
(ie: use --start-after-connect=whatever)
For multimonitor setups, libfakeXinerama helps in some rare cases:
https://xpra.org/trac/wiki/FakeXinerama
But this is not packaged for Debian or Ubuntu yet.
The alternative is to use Xvfb in /etc/xpra/conf.d/55_server_x11.conf
Xvfb starts with a fixed DPI value and will not adapt to the client's
screen resolution. Which means that applications that honour Xft/DPI
will have the "correct" DPI, whereas applications that use a calculated
"hardware DPI" will get the fixed DPI value.
Xvfb has the small disadvantage of not supporting some of the more
advanced input device virtualization features like precise scrolling:
https://xpra.org/trac/ticket/1611
How?
Post by Perry E. Metzger via shifter-usersis now accepted and the emacs I launch no longer looks crazy. When I
set the DPI to 110 (which is closer to what is actually true on my
screen) the emacs ends up a bit distorted again, with the width of the
display not being 80 columns when it first comes up. I'm not sure why.
If you think this is a bug that should be fixed, please file a ticket.
Post by Perry E. Metzger via shifter-usersPost by Perry E. Metzger via shifter-usersIs there a chance of contributing these patches upstream? It would
help.
It really would....
As I said in my other reply, that's very unlikely to be accepted, ever.
(even though we are the primary users of the dummy driver and the
solution is small and reliable, it is just not very "clean")
Post by Perry E. Metzger via shifter-usersPost by Perry E. Metzger via shifter-usersAnd can I install the patched Xdummy somewhere non-standard and
point xpra at it? I imagine that something in /etc/xpra/* will let
me do that but I don't know how.
For now I just did a dpkg -i on the generated .deb but I have to
confess I don't know what will happen if the thing gets
overwritten. My unix fu is stronger than my dpkg fu.
This build has a newer version number than the one available in the
standard Ubuntu repositories, so it is very unlikely to be replaced
during system updates.
Cheers,
Antoine