131–140 of 192 posts
HPDI support on Linux is terrible. After stuggling to make it work consistently accross various applications on my Dell XPS 13 with HDPI screen, I conciously choose my next laptop to have just HD screen. I am so happy as everything is finally working normally.
Earlier quoted context omitted.
Like I said, it is something that should be pull requested to the upstream, and if that fails, then fork. The fork is a secondary path to cooperation. If the conclusions are that the platform cannot support cursor acceleration the proper way (i.e. the way all commercial OSes do), the premise of the library is flawed. If not, then it must be the whole OS that's flawed, because that needs to be possible on a desktop sy…
I think "there is only one person working full-time on maintaining Linux input libraries and he's overworked" is probably a decent excuse. I don't know what you plan to do, but I would advise against forking unless you can hire a team to accumulate testing hardware and work on this for multiple years. What we have seen too often is these forks just fizzle and get forgotten, especially if they are only focused on gett…
Earlier quoted context omitted.
Yep. Windows 10 is fantastic in this regard. MacOS on the other hand sucks. Basically the recommendation is to run a lower and blurry resolution if you want bigger buttons and text... At the same time, iOS has great scaling and text sizing options, and macOS’ interface is so abstract that it should be very easy to vectorize it, enabling seamless scaling to any size wanted. Really baffling.
I'm sorry what? I've used Windows 10 scaling and it looks horrible compared to MacOS native 2x HiDPI scaling. The computers are made for HiDPI or not and it looks very natural compared to windows which doesn't scale all elements by the same amount.
Earlier quoted context omitted.
I think "there is only one person working full-time on maintaining Linux input libraries and he's overworked" is probably a decent excuse. I don't know what you plan to do, but I would advise against forking unless you can hire a team to accumulate testing hardware and work on this for multiple years. What we have seen too often is these forks just fizzle and get forgotten, especially if they are only focused on gett…
I’ve heard of tons of these patches people write for libinput, yet they are never in master. There’s nothing in the libinput README or FAQ about how they’re looking for help, and there are quite a few different authors. How is anyone supposed to know help is needed?
i still got the patches somewhere and will post them soon. it basically let you set mouse speed scaling on a larger scale
Earlier quoted context omitted.
I think "there is only one person working full-time on maintaining Linux input libraries and he's overworked" is probably a decent excuse. I don't know what you plan to do, but I would advise against forking unless you can hire a team to accumulate testing hardware and work on this for multiple years. What we have seen too often is these forks just fizzle and get forgotten, especially if they are only focused on gett…
I’ve heard of tons of these patches people write for libinput, yet they are never in master. There’s nothing in the libinput README or FAQ about how they’re looking for help, and there are quite a few different authors. How is anyone supposed to know help is needed?
I was actually surprised when using a 2020 Mac that macOS doesn't actually support scaling on external displays. It seems that Linux/Wayland is on the lead here.
Earlier quoted context omitted.
> This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. From your link: """ > While rendering at rational factor can't be of better quality, it can > however be done at a much higher quality than downscaling, faster and with > less memory usage. Perhaps, but that…
The solution in that email is essentially how it works, the only difference is that the scaling factor is forced to be an integer. >By faking them out and telling them "here's a 200x200 box to do your work" and then later scaling down that box to 150x150 prevents that code from working properly. Then question I was getting at is: how do you write a renderer that does the right thing and works properly when given a bo…
> It actually is much worse for the one that doesn't match, because now you have lost the ability to do pixel-perfect scaling.
I don't know what you mean by this. Pixel perfect scaling is precisely what's not possible right now. If you have a 1.3x screen and a 1.5x screen you can't render 1:1 to any of them. With this you could at least have 1:1 in the 1.5x screen and be pixel perfect there.
Earlier quoted context omitted.
You already have to propagate code all over to handle integer multiples, don't you? The email seems to be worried about things happening at the wayland level with fractions, but that's easily solved by rounding entire windows to the nearest pixel.
You do have to propagate the scaling factor, but as long as it's an integer scale, you don't have to convert all your coordinates to use floating-point everywhere and enforce rounding rules. I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. The only real way I know to do this without causi…
Earlier quoted context omitted.
You already have to propagate code all over to handle integer multiples, don't you? The email seems to be worried about things happening at the wayland level with fractions, but that's easily solved by rounding entire windows to the nearest pixel.
You do have to propagate the scaling factor, but as long as it's an integer scale, you don't have to convert all your coordinates to use floating-point everywhere and enforce rounding rules. I'd also like to point out that if you are rounding in your rendering anywhere, you are now likely either introducing blurriness again, or something is getting scaled incorrectly. The only real way I know to do this without causi…
Some things will be blurry, but no worse than having the compositor do it. Other things will not be blurry, and that's a huge huge benefit.
> artifacts or error build-up
Integer multiples risk artifacts too, if the program is actually supposed to be rendering in high resolution. Error build-up I'm not sure should be a big worry when you can have 53 bits of precision for a window a couple thousand pixels across.
> As you describe, this is the "easily solved" way
I'm not sure you understood what I meant. I was saying that when possible the compositor should round the window to the nearest pixel, then have the client render at that resolution, so then the compositor would not do any scaling at all.
Credit where credit is due this is the one area where Windows is the best OS these days. It not only will do fractional scaling but it will do display independent fractional scaling - whack in the scaling percentage on each screen and in the recent versions of Windows 10 it works well and looks great and remembers your settings when you plug that monitor back in. It is perhaps THE thing along with WSL2 (now giving me…
I've also read the opposite opinion about macOS - namely, that it's the platform that does it best. I've ordered my first Mac (mini). It's arriving in 2 weeks. Will see then.
Overall, poor HiDPI support on Windows is one of the main reasons why I decided that I don't want to switch to Windows as my main driver and instead try macOS.
[1]: GNOME on the other hand is terrible. It's possible to get i3 to work with HiDPI, but there's no end to the work you need to perform to do that.