-
Notifications
You must be signed in to change notification settings - Fork 39
Is HiDPI possible? #4
Comments
Yup, that's exactly what I've tried fiddling with!
Note that the advertised screen sizes are what OS X wants, not the true panel size. Both are actually 2x that. I've also tried (all are active now):
When I turn of the 2x scaling on the OS, I get the correct output on Xpra, with the desired 1x1 pixel mapping.
The reason I cannot go with this workaround is that it makes everything else on the system incredibly small. |
I forgot to mention: setting |
@aisamu You can try using XQuartz instead of Xpra it will give you better performance and probably solve the problem. |
Good call! Is there a way to advertise a forced, fake screen size (2x) to Xpra? |
@aisamu Hmm. I think you should ask at https://www.xpra.org/ they helped me a ton when I had feature request, found bugs. @aisamu Btw can you try XQuartz and Xpra with something like Firefox? Just to make sure that we aren't searching for a problem in a wrong place. |
Tested Firefox with XQuartz, same behavior. (followed this: https://fredrikaverpil.github.io/2016/07/31/docker-for-mac-and-gui-applications/) Firefox with Xpra is interesting. With the DPI flags set to 192, FF renders as if it were on a HiDPI display, but at twice the size! Turning down the desktop-scaling to 0.5 brings it back to the correct size, but the DPI is reduced as well. So close! |
Firefox with Xpra using the web client behaves as the local client with DPI flags set: rendered as a HiDPI app, but at twice the size. (even with the DPI flags unset) |
I've asked on xpra's IRC channel and I was told the version we're using ( |
@aisamu We use dummy from Alpine repo https://pkgs.alpinelinux.org/package/edge/main/ppc64le/xf86-video-dummy |
You can try build Xpra with a different version https://github.com/JAremko/docker-x11-bridge/blob/master/Dockerfile#L6 and submit PR if it works. You can figure out what is the latest one from by looking here https://www.xpra.org/src/ |
I'm trying to build it with version 2.3, but the |
@aisamu Usually it means that Xpra changed its dependencies and we need to add new packages and stuff. Look into build log 😉 |
OK, will check!
|
@aisamu replace it with gst-plugins-base, gst-plugins-good, gstreamer |
@aisamu Packages in Alpine got renamed (for some reason) when you have error like this try searching with a wild cards (i.e. It's a painful process 🙀 |
Thanks for the hand-holding, I'm really out my depth here! |
Changes so far
Observed non-breaking error:
Currrent breaking error:
|
@aisamu Alpine now has Xpra package https://pkgs.alpinelinux.org/package/edge/community/s390x/xpra So we probably don't even need to build it. Unless it lacks some really needed features 🤔 |
@aisamu try something like this https://gist.github.com/JAremko/e7478e514e050aa53a99b8e0be24c84f We might not need |
Tried the gist this morning!
After building and running it, we get:
I'll try now just switching the compilation with the xpra package in the original Dockerfile. |
:hair-pulling: (The previous changes also apply)
# Deps
+ xpra \
# Xpra
- && curl https://www.xpra.org/src/xpra-$XPRA_VERSION.tar.xz | tar -xJ \
- && cd xpra-$XPRA_VERSION \
&& echo -e 'Section "Module"\n Load "fb"\n EndSection' \
>> etc/xpra/xorg.conf \
- && python2 setup.py install \
- --verbose \
- --with-Xdummy \
- --with-Xdummy_wrapper \
- --with-bencode \
- --with-clipboard \
- --with-csc_swscale \
- --with-cython_bencode \
- --with-dbus \
- --with-enc_ffmpeg \
- --with-enc_x264 \
- --with-gtk2 \
- --with-gtk_x11 \
- --with-pillow \
- --with-server \
- --with-vpx \
- --with-vsock \
- --with-x11 \
- --without-client \
- --without-csc_libyuv \
- --without-dec_avcodec2 \
- --without-enc_x265 \
- --without-gtk3 \
- --without-mdns \
- --without-opengl \
- --without-printing \
- --without-sound \
- --without-webcam \
&& mkdir -p /var/run/xpra/ \
- && cd ../.. \
- && rm -fr xpra-$XPRA_VERSION \ The build works, but the run fails with:
|
Yeah this Debian and Ubuntu have I'll probably try building Xpra to figure out when it broke. |
@aisamu Looks like I managed to fix it and update to the latest version |
@aisamu You can try building dummy with patches from https://xpra.org/trac/wiki/Xdummy#Status but it will require coding in C 🤔 It may help you https://git.alpinelinux.org/cgit/aports/tree/main/xf86-video-dummy/APKBUILD |
😭 |
Now we use patched dummy. @aisamu When it finishes building you can try again with the new image. |
@aisamu Added another update - removed stuff that seems to be no longer needed. Now it needs good testing |
@aisamu What Xpra ppl saying about it? 🤔 |
We use latest Xpra with latest dummy patched with all 3 xpra patches (without conflicts) |
@aisamu The only somewhat reasonable thing I can think about at this point is fiddling with /etc/xpra/xorg.conf Mb try removing/adding some resolutions to force it into hiDPI mode. Also try removing this section - it is at the end of the /etc/xpra/xorg.conf file 🤔 |
Removing the
|
@aisamu So if you use default Xpra config it doesn't start... 🤔 |
Mb there is something interesting in |
Tried it again with the contents of the link and got the same result :/ |
@aisamu That's probably a good thing. There is a real probability that this |
Here are the contents of Xorg.:14.log
|
@aisamu And if you use |
aha https://git.alpinelinux.org/cgit/aports/commit/?id=8fc1aaee7f27d1ac317b7b39a1dc8c4182ce5fec
|
So this is why I added this section. Should document next time 😕 |
Here are the contents of Xorg.:14.log with
|
@aisamu |
No! I ask for 192 everywhere that I could think of...
Client is started with:
And the relevant client |
May be if you start Xorg from Xpra like in https://xpra.org/trac/wiki/Xdummy it will help 😕
Here's how we start Xorg (you can comment it out or set And here's how we start Xpra (add Did some asking about |
If the OS is lying to xpra, then xpra doesn't stand a chance to paint things with the desired geometry.
FYI: this is only useful for applications that try to calculate their own DPI based on the screen geometry.
This only affects video encoders. Unless your application is refreshing the screen at 10fps or more, this won't make any difference.
Sounds like it is the other applications that need to adapt properly to the DPI, not xpra.
No, and even if there was one, it wouldn't help: xpra would still be painting using APIs that pretend to be a different size. There is nothing you can do server side. Just in case (unlikely IMO), you may want to try the macos beta builds based on the newer python3 / gtk3 toolkit: (https://xpra.org/beta/osx/ xpra macos beta builds) |
@totaam Thank you for the input!
Xpra is being correctly rendered, but as a non HiDPI-aware OS X app. What I meant is that my end goal is to have Xpra rendering using the "real" pixels, as a HiDPI app, even if that means the underlying application will be extra-small (since there's not necessarily support on X11 or by the app).
I'll keep my fingers crossed!
Gave it a try, but it won't start :/ And thanks for this great software :) |
Please file an xpra ticket so this will get looked at. |
Is there a way to get HiDPI from X programs, or at least a small-but-crisp rendering?
My current (only) target is spacemacs-docker, and running it right now gives me correctly sized but very blurry text. I imagine it is rendered on a lower resolution and then upscaled.
I've tried changing
XORG_DPI
(env),XPRA_DPI
(env),desktop-scaling
(xpra.conf), but I'm limited by my lack of knowledge on both Xpra and X11.The current workaround is to disable the system "2x" scaling, so that Xpra receives the correct screen size (4k) and renders the output accordingly. It is indeed very small, but I can increase the font size and have normal-sized, crisp text.)
Please let me know if you'd like me to check/test something that I've missed.
This is an absurdly amazing tool!
Thank you very much!
The text was updated successfully, but these errors were encountered: