<div dir="ltr">Have the X emulator assume the client set the scale to the one determined from the dpi in the .Xresources?<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 8, 2015 at 6:10 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, Nov 07, 2015 at 09:48:59PM +0100, Michael Stapelberg wrote:<br>
> Hey,<br>
><br>
> I just got around to trying Wayland on my ThinkPad X1 Carbon 2015.<br>
><br>
> The machine has a 2560x1440px display with 220 DPI, hence I’m using it as a<br>
> “retina display”, i.e. with a scale factor of 2. On Xorg, I achieve this by<br>
> setting “Xft.dpi: 192” in my ~/.Xresources. All the applications then come<br>
> up with crystal-clear text, in comparison to a regular 96 dpi screen at<br>
> least… :)<br>
><br>
> When running weston without a ~/.config/weston.ini, everything is rendered<br>
> with the native resolution of 2560x1440px, meaning the text is unreadably<br>
> small (see the left weston-terminal window in<br>
> <a href="http://t.zekjur.net/xwayland-scale-1-x.png" rel="noreferrer" target="_blank">http://t.zekjur.net/xwayland-scale-1-x.png</a>).<br>
><br>
> Therefore, I’ve set the following in my ~/.config/weston.ini:<br>
><br>
>   [output]<br>
>   name=eDP-1<br>
>   scale=2<br>
><br>
> This is recommended on<br>
> <a href="https://wiki.archlinux.org/index.php/Wayland#High_DPI_displays" rel="noreferrer" target="_blank">https://wiki.archlinux.org/index.php/Wayland#High_DPI_displays</a>, but I’m not<br>
> sure if it’s actually the best method or the desired end state of hi-dpi<br>
> support in wayland/weston. My uncertainty stems from the fact that while<br>
> text in weston-terminal is rendered clearly, all assets (icons, mouse<br>
> cursors) are low-resolution, even though higher-resolution versions are<br>
> available.<br>
><br>
> For the actual issue I’m trying to describe, my test procedure is to use<br>
> “xrdb ~/.Xresources && urxvt”, then place the urxvt window such that it<br>
> occupies about half of the screen.<br>
><br>
> With scale=2 (see <a href="http://t.zekjur.net/xwayland-scale-2-x.png" rel="noreferrer" target="_blank">http://t.zekjur.net/xwayland-scale-2-x.png</a>), I get a<br>
> window with about 640px width in xwininfo and an extremely big font. I<br>
> suppose this is because the Xwayland window (is that how it works?) is<br>
> scaled to 2x.<br>
><br>
> With scale=1 (see <a href="http://t.zekjur.net/xwayland-scale-1-x.png" rel="noreferrer" target="_blank">http://t.zekjur.net/xwayland-scale-1-x.png</a>), I get a<br>
> window with about 1280px width in xwininfo and the font I expect.<br>
><br>
> So, it seems to me that I have to use scale=2 to get wayland apps to render<br>
> correctly on a hi-dpi screen, and scale=1 to get xwayland apps to render<br>
> correctly on a hi-dpi screen, and I obviously can’t do both at the same<br>
> time.<br>
<br>
</div></div>Pretty much. weston pretty much assumes that X11 clients are simply just<br>
not HiDPI capable, and will just scale up as if it was a Wayland client,<br>
and this produces this result.<br>
<br>
As a side note, in mutter we currently don't scale up Xwayland client<br>
surfaces because of this reason; in GNOME, clients tend to be rendered<br>
with respect to the DPI (i.e. at double the scale if the DPI is high<br>
enough), and since the X server has no clue about the scale in use, it<br>
will always set the buffer scale to 1. Pointer cursors has the same<br>
issue; the X side of things might be aware of it (but without the actual<br>
X server having any idea of what's going on).<br>
<br>
An issue with this is that non-DPI-aware X clients will look very tiny;<br>
but this since that wasn't really a regression from before, we are<br>
currently living with it. Another issue is that even though the display<br>
server is aware of each monitor's individual DPI, X11 windows will not<br>
adapt their size to the monitor.<br>
<br>
A possible way to deal with this in the future is to add per window<br>
properties specifying the scale the client actually drew its content<br>
with, an X11 equivalent of wl_surface.set_buffer_scale more or less.<br>
This might be problematic though because of race conditions and what<br>
not, and I'm not aware of it being tried out anywhere.<br>
<span class=""><br>
><br>
> Shall I file a bug about this, or am I misunderstanding something?<br>
<br>
</span>Feel free to report one. I took a quick look, but couldn't see any<br>
existing bug in the fdo bug tracker which covers this.<br>
<br>
<br>
Jonas<br>
<br>
><br>
> Thanks,<br>
> Best regards,<br>
> Michael<br>
<br>
> _______________________________________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div><br></div>