[winswitch] xpra dpi - (was: woes with a server running Ubuntu cosmic)

[Antoine Martin]

On 12/09/2018 20:07, Perry E. Metzger via shifter-users wrote:
> On Wed, 12 Sep 2018 08:43:56 -0400 "Perry E. Metzger via
> shifter-users" <shifter-users at lists.devloop.org.uk> wrote:
>>>> My 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...)
>>
>>> Everything you need should be here:
>>> http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy
> 
> BTW, thanks!
> 
>> Do 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

> but setting things to 72
How?

> is 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.

>> Is 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")

>> And 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

> 
> Perry
>