ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
privacy has quit [Remote host closed the connection]
julio7359 has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
kenny has quit [Quit: WeeChat 4.2.1]
mclasen has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
qaqland has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
julio7359 has quit [Remote host closed the connection]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
kenny has joined #wayland
guru_ has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
guru__ has quit [Ping timeout: 480 seconds]
silverpower_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest4136
Guest4045 has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
glennk has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
kts has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
Guest4136 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4140
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
Leopold___ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
guru__ has quit [Ping timeout: 480 seconds]
kchibisov_ has quit [Ping timeout: 480 seconds]
pitust_ has quit [Ping timeout: 480 seconds]
mainiomano_ has quit [Ping timeout: 480 seconds]
rpigott has quit [Ping timeout: 480 seconds]
kchibisov has joined #wayland
Company has quit [Quit: Leaving]
rpigott has joined #wayland
pitust has joined #wayland
mainiomano has joined #wayland
ofourdan has quit [Remote host closed the connection]
ofourdan has joined #wayland
mtretter has quit [Remote host closed the connection]
mtretter has joined #wayland
shoragan has quit [Quit: quit]
shoragan has joined #wayland
ManMower has quit []
mxz has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
ManMower has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
sima has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
JEEB has quit [Remote host closed the connection]
rawoul has quit [Remote host closed the connection]
JEEB has joined #wayland
rawoul has joined #wayland
systwi has joined #wayland
ofourdan has quit [Remote host closed the connection]
mtretter has quit [Remote host closed the connection]
qaqland has quit [Ping timeout: 480 seconds]
mtretter has joined #wayland
ofourdan has joined #wayland
tomamoto has joined #wayland
tomamoto has quit [Remote host closed the connection]
qaqland has joined #wayland
mxz has joined #wayland
rasterman has joined #wayland
narodnik has quit [Quit: WeeChat 4.2.1]
narodnik has joined #wayland
mvlad has joined #wayland
rv1sr has joined #wayland
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
manuel1985 has joined #wayland
glennk has joined #wayland
garnacho has joined #wayland
ghishadow has quit []
ghishadow has joined #wayland
mart has joined #wayland
ghishadow has quit [Remote host closed the connection]
<immibis>
Nova[m]: well idk the best solution either, just pointing out something to consider - program session restore probably shouldn't be an exclusive Wayland thing
<immibis>
Command-line programs might also want to be restored
<wlb>
wayland/main: David Benjamin * util: fix undefined behavior in wl_array_for_each https://gitlab.freedesktop.org/wayland/wayland/commit/8a7ecd774c40 tests/data/empty-client.h tests/data/empty-code.c tests/data/empty-server.h tests/data/empty.xml src/wayland-util.h tests/scanner-test-gen.sh tests/scanner-test.sh
ghishadow has joined #wayland
Serus has quit [Ping timeout: 480 seconds]
lbia has quit [Quit: lbia]
Serus has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
Serus has quit [Ping timeout: 480 seconds]
Serus has joined #wayland
kts has joined #wayland
garnacho has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #wayland
kts has quit [Quit: Leaving]
lbia has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
Serus has quit [Ping timeout: 480 seconds]
Serus has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
flom84 has joined #wayland
flom84 has quit [Remote host closed the connection]
kts has joined #wayland
nerdopolis has joined #wayland
fmuellner has joined #wayland
Zeroine has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
lbia has quit [Quit: lbia]
lbia has joined #wayland
<Shinri>
Hi all, I recently found my numlock and capslock don't work well in Wayland, when I switch to an app like Firefox, neither of these two keys work correctly
<Shinri>
I've tested qt, gtk in mutter, wester and Kwin but nothing works, it just appear like this
<Nova[m]>
<immibis> "Nova: well idk the best solution..." <- after talking with friends i think the best thing to do is a d-bus service and env var, making in total an XDG base spec
<Company>
after the fractional scaling fun with GTK for the last few weeks, I've come to 2 conclusions about fractional scaling:
<Company>
1. fractional scales should be thought about as a fraction of 2 integers, and both those integers should be small
<Company>
ie 3/2 instead of 150%
<Company>
and they should never be something like 329/120
<Company>
2. the numerator of that fraction should divide both the width and height of the monitor's pixel resolution
<Company>
that ensures that you end up with an integer for the scaled monitor size, which means fullscreen windows have an integer size
<Company>
and if you make sure your panel has a proper size, maximized windows end up with an integer size, too
privacy has quit [Remote host closed the connection]
privacy has joined #wayland
<ManMower>
I find fractional scaling looks best when the numerator is a multiple of the denominator.
<Company>
there's still a bunch of issues with making that approach work well - like the fact that the forced 120 denominator in the protocol means you cannot use 7 or 9 or 16 as your denominator (no idea why you'd want to use 7, but I could imagine 9 or 16
<zamundaaa[m]>
Company: ensuring that you always end up with integers is not really possible
<Company>
and the fact that the buffer rounding algorithm often doesn't work as scales get close to 2
<Company>
zamundaaa[m]: why not?
<zamundaaa[m]>
Because you have a lot of different sizes where it all needs to work. Width, height of the screen, height of the panel + height of the maximized window, width of windows tiled in various configurations, or just aligned next to each other manually by the user
<zamundaaa[m]>
Depending on the window decoration, you additionally get 2px line additions to a lot of these sizes
<zamundaaa[m]>
that said, adjusting the scale is something I've thought about too, but on a per window basis
<Company>
sure, in those cases you need to get creative, but with (1) you can ensure that the panel doesn't look too bad and adjust the configurations slightly so that they fit
<zamundaaa[m]>
The compositor can't really do it that well, but a toolkit could nudge it a bit in one or the other direction when rendering
<Company>
at least I think you can
<psykose>
ManMower: isn't that just not fractional? those are whole integers
<ManMower>
psykose: must be why it looks so nice. ;)
<psykose>
...
manuel1985 has quit [Ping timeout: 480 seconds]
iomari891 has quit [Read error: No route to host]
<mclasen>
the numerology with 120 is nonsense
<Company>
zamundaaa[m]: my example is always 1440p, because 2560 is not divisible by 3
<Company>
zamundaaa[m]: so you probably don't want to offer 150% as a scale factor there
<Company>
and instead pick a fraction that's close but does divide 2560
<Company>
5/3 maybe or 16/10
junaid has quit [Quit: Lost terminal]
nerdopolis has joined #wayland
<kennylevinsen>
The alternatives wasn't better. 255 made common values borked, and i doubt the aggressive resolution of a uint32 denominator would do anyone any good.
<zamundaaa[m]>
higher resolution couldn't have made it worse in any way
<kennylevinsen>
Doesn't mean it would make it better in any way :)
<mclasen>
I don't see any problems with just sending a proper fraction
<mclasen>
its not like we're size limited
leon-anavi has quit [Quit: Leaving]
<kennylevinsen>
Of course not, but what is the use case that is not reasonably handled by a fixed denominator?
<Company>
all the numbers that aren't divisible by 120
<kennylevinsen>
(granted, the decision for 120 over wl_fixed sometimes keeps me up at night, but the author of wl_fixed also protested against its use as 255 is a terrible denominator)
<Company>
technically, a fixed numerator would be way less problematic
<kennylevinsen>
Company: and you need 100.83% scaling?
<Company>
I need a scale factor close to 150% that divides 2560 and 1440
<mclasen>
the whole idea of sending scale factors is questionable, imo. Because it makes for endless games with rounding modes
<Company>
closest one you can get is 160/107, but if the denominator is forced to be 120, I think 16/10 is the closest you can get?
<kennylevinsen>
that's true, and for all intends and purposes it was a workaround to proceed
<kennylevinsen>
mclasen: but it's also rather unwayland-like to have the compositor control dimensions, so the client has to be able to come up with the right buffer dimensions one way or another
leon-anavi has joined #wayland
<kennylevinsen>
zamundaaa[m]'s proposal was to effectively allow the client to operate in coordinate space matching the physical coordinates of a particular monitor, but I believe that stalled
leon-anavi has quit []
<kennylevinsen>
I imagine we'll have gathered enough complaints^W thoughts for a v2 at some point.
<Company>
"at some point" will probably be rather soon
<Company>
once Gnome's fractional scaling hits the distros
<zamundaaa[m]>
well, I thought I had gathered enough two years ago, but yes, we've now also seen these issues in practice
<Company>
or I guess KDE6?
<zamundaaa[m]>
I have been working on fractional scaling stuff again and will update the MR + implementation soon
<Company>
does KDE6 do the full fractional dance from compositor to client?
<kennylevinsen>
two years ago Gtk also said fractional scaling would be practically impossible before Gtk5, so we had a smaller pool of interested parties for discussion
<zamundaaa[m]>
v2 didn't fail to succeed because of the client side really, it was mostly compositor developers that weren't happy about it
<Company>
(it was a contentious topic in GTK, but I tricked them all!)
<Company>
because GTK still doesn't do fractional scaling really
<Company>
GTK's renderer does though
<zamundaaa[m]>
Company: what do you mean with "the full fractional dance"?
<kennylevinsen>
Even in the current state I'd say we're in a much better place than we used to - our common attitude used to be that fractional scaling was an impossibility, now we have tried it and can improve it...
<Company>
zamundaaa[m]: the compositor offers fractional scales in its configuration and the panels clients render to that chosen scale factor (instead of downscaling from 2x)
<kennylevinsen>
zamundaaa[m]: I'll need to look at the proposal again, I forget the details
<Company>
*panels and clients
<Company>
I think the proposal was better, but I'm not sure it solved the bigger problems
<zamundaaa[m]>
Company: all Qt 6 apps do fractional scaling, yes
<Company>
and kwin does it, too - and KDE6 is Wayland, so it works there, too
<Company>
which means we're all currently waiting for the April distro release when millions of people will try it and find all the issues
<Company>
(on top of the ones that people have already found)
<zamundaaa[m]>
People have been using Plasma 6 on Arch and on prerelease Fedora 40 for a while and we haven't had too many complaints about fractional scaling
<zamundaaa[m]>
There's even users that say it's better than Windows already
<Company>
it is absolutely better than windows
<Company>
because any form of scaling on windows is a catastrophe
<zamundaaa[m]>
Nah it works quite well, at least as long as you only have one display
<zamundaaa[m]>
If you have two with different scaling and move windows between them, that is really terrible
<Company>
my favorite thing about Windows is that the old Winamp I'm still using isn't scaled, so it's about as big as the firefox titlebar
privacy has quit [Remote host closed the connection]
<Company>
and if they also have different refresh rates and fullscreen stuff, Windows falls apart entirely
<Ermine>
fractional scaling is good as long as xwayland is not involved...
<zamundaaa[m]>
We do have gaps between the panel and maximized windows at some scale factors too
<Company>
I wonder what Windows does there
<zamundaaa[m]>
Windows uses device pixels
<zamundaaa[m]>
What toolkits on Windows do to deal with that though I don't know
<Company>
neither do I - but knowing the state of the GTK backend, it probably rounds one way or the other
<Company>
likely it doesn't offer fractional scales even
<zamundaaa[m]>
For the vertical size case specifically I've had the idea of masking the issue by scaling the title bar a little bit, which would work with server side decorations at least
<zamundaaa[m]>
It might be that the system library that paints the title bar in Windows does something like that too
<LaserEyess>
fwiw, windows 10 at least has those same "off-by-one" errors for certain things, too
<LaserEyess>
especially with title bars
feaneron has joined #wayland
<Company>
zamundaaa[m]: I would scale the title bar, too, so it fills that seam. I might even adjust the scale factor of the panel to make it look good
<Company>
but I'll leave that up to the shell guys to figure that out
<Company>
it's why I want small numbers in the numerator
<Company>
so rounding to the next pixel boundary isn't too big of a difference
<Company>
and then you have integers for both and avoid problems
<Company>
*integers in application space
<Company>
it's tricky to get that right with my example above of course
<Company>
if you want to offer 150% on 1440p, you'll not have integers
<Company>
but if you go with 166% or 133%, you have 5/3 or 4/3 and then you can scale the panel to a multiple of 5 or 4 pixels and you don't have seams
<Company>
and that approach works for fancier setups with multiple panels, too
<Company>
but it does restrict the scale factors you can offer
dos1 has joined #wayland
dos11 has quit [Read error: Connection reset by peer]
___nick___ has joined #wayland
__nick__ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]