ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
slattann has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
txtsd has quit [Quit: WeeChat 3.5]
slattann has quit []
lsd|2 has quit []
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
slattann has joined #wayland
shankaru has joined #wayland
naveenk2 has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
danvet has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
everfree has quit [Remote host closed the connection]
everfree has joined #wayland
ts has joined #wayland
spstarr has quit [Remote host closed the connection]
spstarr has joined #wayland
mvlad has joined #wayland
spstarr has quit [Remote host closed the connection]
eroux has joined #wayland
shankaru has quit [Quit: Leaving.]
eroux has quit [Ping timeout: 480 seconds]
creich has quit [Quit: Leaving]
tzimmermann has joined #wayland
ts has left #wayland [#wayland]
uu has joined #wayland
<uu>
77
spstarr has joined #wayland
shankaru has joined #wayland
ibrahimcetin has joined #wayland
eroux has joined #wayland
ibrahimcetin has quit []
hardening has joined #wayland
jmd has quit []
jgrulich has quit [Remote host closed the connection]
rpigott has quit [Ping timeout: 480 seconds]
lxsameer3 has joined #wayland
rasterman has joined #wayland
jgrulich has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
rpigott has joined #wayland
maxzor has joined #wayland
shankaru has quit [Quit: Leaving.]
eroux has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
ecloud_ has quit [Ping timeout: 480 seconds]
uu has quit [Quit: Leaving]
shankaru has joined #wayland
ecloud_ has joined #wayland
gramar_ has joined #wayland
gramar_ has quit []
gramar has joined #wayland
eroux has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
<ifreund>
what's up with xkb_state_key_get_one_sym() vs xkb_state_key_get_syms()? The docs don't really explain in what situations multiple keysyms may be returned and how that should be handled...
<ifreund>
Is it fine to just use xkb_state_key_get_one_sym() in practice as the docs seem to suggest? If so why does the version returning multiple exist?
eroux has quit [Ping timeout: 480 seconds]
txtsd has joined #wayland
<kennylevinsen>
> libxkbcommon also supports an extension to the classic XKB, whereby a single event can result in multiple keysyms
<ifreund>
kennylevinsen: ok, so users could configure their xkb keymap to have a sort of "macro key" that yields the string "hello" on press? Interesting
<kennylevinsen>
ifreund: I guess it's a neat feature, but I was never much of a keyboard-level-macro guy so...
<kennylevinsen>
I'd rather make the application react to that key properly than fake input
<ifreund>
Yeah, same. I do use a custom keyboard with qmk firmware but I don't do any macro stuff with it, just layers and some multipurpose keys
<ifreund>
my xkb config is all default
<kennylevinsen>
+1 for qmk :P
erc_ has quit [Ping timeout: 480 seconds]
eroux has joined #wayland
<kennylevinsen>
d_ed: "Dave went on a rant" hah
<kennylevinsen>
Looks accurate, action points seem fine. vyivel got a lead on me for test clients, but there's of course more places in the API using logical pixels than what is tested.
<kennylevinsen>
That also immediately triggered new rounding approach discussions as the test caused ideas to emerge
<pq>
kennylevinsen, btw. was the idea of separating resolution from UI size factor dropped, or is it still there?
<kennylevinsen>
pq: I remember one of the issues maintained a separation but I'm not sure what benefit that would bring. My current proposal behaves like the existing surface scale made fractional.
<pq>
Fundamentally drawing resolution and UI size are orthogonal and mostly independent factors. Projector vs. monitor vs. smartphone display.
<pq>
The only thing that does not work is small UI on coarse resolution as that becomes illegible when resolution is not enough to represent UI details like glyphs.
<pq>
Otherwise resolution is dictated by hardware, and a comfortable range of UI scales by the eye distance to the image.
fmuellner has joined #wayland
shankaru has quit [Quit: Leaving.]
<kennylevinsen>
pq: the factors (preferred UI size and output resolution) are orthogonal, but the buffer scale is the two multiplied together. Is there a case where that would not be sufficient?
<pq>
I mean in the compositor->client direction, not buffer scale.
<kennylevinsen>
Note that we considered DPI matching / defining "physical" sizes of content to be a non-goal for complexity reasons, so the scale of an output is solely based on "user wants it yay big".
<pq>
I totally agree with that.
Company has joined #wayland
The_Company has joined #wayland
<kennylevinsen>
well, compositor->client and client->compositor is effectively the same: compositor sends the *preferred* buffer scale (for "normal" compositors, the intersecting output it finds most important), clients sends a buffer at some scale. Compositor scales result as needed.
The_Company has quit []
<kennylevinsen>
If we decoupled the two you'd be able to increase the UI size without increasing the buffer size (and thus still be compositor scaled), but is there a use case for that?
Company has quit []
Company has joined #wayland
<pq>
I have a use case: elderly people may need big UI size to see it right, on a monitor that a normal "1x" resolution. I would want to keep apps drawing at 1x resolution, but just make the UI bigger.
<kennylevinsen>
Having a monitor that is "1x resolution" and wanting a UI that is 5x bigger is no different than having a "5x resolution" monitor: Both give an output scale of 5. You can use our integer scaling for that too right now - if stuff is too small, set 2x scale to make it bigger. Doesn't need to be a high DPI monitor.
<pq>
you mean having a 0.2x resolution monitor?
<kennylevinsen>
I think our terminology is decaying...
<pq>
oh, yeah, my mistake
<pq>
I mean, one major point here is that apps can render at the output physical resolution, right?
shankaru has joined #wayland
<kennylevinsen>
My point is that whether you want stuff twice as big because the screen is high DPI, small, far away, has poor contrast or some other reason all just contribute to your chosen output scale. The only reason I use a higher scale on my 13" 4k laptop is exactly because stuff is tiny which is the same scenario as poor visual acuity on a lower resolution screen.
<pq>
hmm, maybe it does work. I'm a fool starting to discuss this in irc. :-)
<kennylevinsen>
no worries
<kennylevinsen>
I'm just worried that I have missed a use-case
<kennylevinsen>
And you *do* tend to have smart things to say :P
<pq>
I just recall we discussed separating resoution from UI size in the past.
<pq>
Thanks. I need to get back to arguing about row vs. column vectors. *sweatsmile*
<kennylevinsen>
there was a discussion about it at some point, but I think that was interleaved with discussions about DPI matching and such
<kennylevinsen>
row vs. colum vectors... :S
<ifreund>
hrm, wl_shm doesn't have a release() request
<pq>
tied to the question or row- vs. column-major storage order of matrices, and whether anything is consistent at all
<pq>
*of
<ifreund>
wl_compositor doesn't either, I guess they were only retroactively added to seats and outputs
<pq>
ifreund, they were, yes
<pq>
they all should have had a "destroy" request from the beginning, but... micro-optimizations
<ifreund>
:/
<pq>
...based on naive assumptions
<Company>
pq: want a fun use case? Magnifiers
<Company>
compositors might want to tell the magnified app to increase scale, so the magnifier looks sharp
<pq>
you mean increase resolution while keeping the UI size the same? ;-)
<kennylevinsen>
that works fine with this proposal as well as wl_surface.scale
<Company>
yeah, and the app moight (not) like that
<kennylevinsen>
you send e.g. output scale * 2 to the client, just as if you had moved it to a higher DPI output
<kennylevinsen>
why would it not like that?
<d_ed>
It's making strong assumptions about how the client should work internally though
<kennylevinsen>
at worst it disobeys the scale
<Company>
yup, it might result in some JS that reformats the whole page
<kennylevinsen>
(which is not an error, just unfortunate)
<Company>
so that in the end the magnifier doesn't magnify but modify
<d_ed>
It's perfectly legal for a client to say "ok, I should be 2x, now I'll reposition things about to make the most of the extra space at native resolution"
<kennylevinsen>
if a client does that then it has bad UX and will glitch around as you move between outputs :/
<Company>
(I have no idea how the web deals with scale)
<kennylevinsen>
Technically legal
<kennylevinsen>
but I can't see how that would not be awful for users
<Company>
in GTK I've been trying to push back against scale being important and trying to make it just a part of the GL transformation matrix
<kennylevinsen>
after all, the general idea is that the surface is defined in surface-local coordinates, so there is no content that can't fit there. It's just that you get more points to sample at higher scale factors.
<Company>
but of course, fonts are insane, so they're pushing back hard
<Company>
fonts will align themselves with the pixel grid though
<Company>
which means text can change size when the pixel grid changes
<Company>
and when text changes size, text widgets in GTK can change size and at that point all bets are off
<pq>
But if one changes resolution and not UI size, there is no extra space added. If the app decides there is now extra space, the app is deciding to make the UI smaller.
<Company>
no idea if we've fixed that madness in GTK4 by disabling all these features
<Company>
the app decides to resize the window
<Company>
at least that's what would happen in GTK
<Company>
so you'd get a surface size renegotiation
<pq>
Change of resolution must not be a resize of window, that's the point of keeping resolution and UI size separate.
<kennylevinsen>
I am not an expert in neither font rendition nor Gtk, so I can't really comment here. The only thing new in the fractional scaling proposal is the misalignment of the surface-local and buffer-local grids.
<Company>
tell that to fonts
<pq>
and yeah, I can imagine font rasterization to be a big pain
<Company>
anyway, just pointing out some examples where scale can cause a mess
slattann has quit [Ping timeout: 480 seconds]
<Company>
no idea how relevant they are to the current discussion
txtsd has quit [Ping timeout: 480 seconds]
<kennylevinsen>
well, it's an implementation detail that toolkits and such would have to deal with of course so it's not entirely irrelevant
<kennylevinsen>
we also previously did not have the ability to tell clients to rescale, which was first proposed in the wl_surface.scale proposal (allowing e.g. VR compositors to change level of detail depending on 3D position)
<Company>
the 3 cases where we in GTK deal with that are fonts, icons (we load 32x32 PNGs on hidpi for 16px icons and scale them) and custom user code that wants to conform to the pixel grid
<Company>
like, I recently discussed with YaLTeR[m] what 100% scale for an image means on hidpi monitore
<Company>
in particular when loading a PNG of a screenshot
<pq>
font hinting... I wonder if using scale for magnifiers is a lost goal from the beginning.
<pq>
it's like "magnify" and "make UI bigger" are two different operations
<kennylevinsen>
subpixel antialiasing ruins all scaling and screen recordings (screenshot or video)
<pq>
hinting is not even about sub-pixel
<kennylevinsen>
then I don't understand the issue :/
<Company>
kennylevinsen: you want to align the stem of the I letter to the pixel grid
<Company>
kennylevinsen: assume it's position is 0.6
<Company>
kennylevinsen: on hidpi you align to 0.5, otherwise to 1.0
<kennylevinsen>
ah so just pixel grid alignment
slattann has joined #wayland
txtsd has joined #wayland
rgallaispou1 has joined #wayland
<kennylevinsen>
that also makes things shift around for integer scale though, so nothing new there
<pq>
does it?
<pq>
I guess due to the "rounding"...
rgallaispou has quit [Remote host closed the connection]
<pq>
hmm, yeah, particularly 1x vs. 2x
shankaru has quit []
shankaru has joined #wayland
MajorBiscuit has joined #wayland
<kennylevinsen>
as for increasing UI scale without increasing the observed window size, that's effectively the same as increasing the buffer scale but decreasing the window size. I do not think there is a difference between having 2x the content in 1x the space at 1x resolution, or 1x the content in 0.5x the space at 2x resolution. The buffer size and rendered content size will be the same.
<pq>
umm... what's "window size"?
<kennylevinsen>
*surface size
<pq>
Surface size is in logical pixels, right? And that determines how much UI elements, glyphs, etc. can fit on the surface without changing UI size.
<Company>
yes
<pq>
decreasing surface size by definition means that you either have less/smaller UI elements, or the UI size becomes smaller; IOW, the "semantic" content much change, not just the rendering of it.
<pq>
kennylevinsen, so I don't think I understood you.
<Company>
(exciting times to be had with X11 there when a WM starts resizing your 2x window to odd sizes)
<Company>
(because X11 uses pixel size, not logical size)
<pq>
*must change
<kennylevinsen>
pq: So, as you say a increasing a UI size toggle makes stuff bigger without changing the size of the surface it goes into, so things have to be changed to cram it all in there. A different buffer scale makes stuff bigger the same way, but makes the surface proportionally larger. If you negate the increased surface size with a negative resize, then the appearance of the two is identical.
<kennylevinsen>
but I don't really see the point
<kennylevinsen>
why would I increase the UI size without increasing the surface size? The user can resize windows as normal
nerdopolis has joined #wayland
<kennylevinsen>
pq: if you're busy with your row/column-vector stuff we can take this later, or possibly in the gitlab discussions. :)
<pq>
I wasn't supposed to discuss this to begin with. :-)
<pq>
I see, a good point. But were we not talking about increasing resolution and not UI size?
<pq>
ah, two different topics mixed up
<pq>
for my example use case, yes, increasing UI size should result in larger windows too, if there is room at least
<zamundaaa[m]>
pq: what you're describing sounds like exactly what normal scaling does though?
<kennylevinsen>
There is a case where the window becomes inconveniently larger than the output, but then that would also happen with a low resolution monitor as-is...
<pq>
kennylevinsen, that's another problem with other solutions.
bittin has joined #wayland
<pq>
zamundaaa[m], I may be thinking in DE UI terms as well, as in, what sliders to expose. Definitely there UI size should be different from drawing resolution / video mode. While latter is per-output, the former would be global.
<pq>
I guess they can translate to a single factor for the protocol...
<zamundaaa[m]>
UI scale is separate from the mode, yes. But that has nothing to do with scaling
<zamundaaa[m]>
The scale is a per-monitor value that does completely everything. I don't see a need for something separate, in the GUI or in the protocol
<kennylevinsen>
pq: yeah I suppose they could be exposed separately from a compositor configuration standpoint to simplify accessibility configuration
<kennylevinsen>
not strictly speaking needed, but it's doable if that's a preference
<kennylevinsen>
it seems to be the status quo on other platforms to expose per-output, but whatever floats the compositor author in question's goat
<kennylevinsen>
now, get back to your vectors!
<pq>
zamundaaa[m], I forgot to mention that in my mental model, the "output scale" slider would not exist. It would be replaced with the video mode + UI size factor.
<kennylevinsen>
I'm assuming you are considering per-output scale adjustments part of the "video mode"
<pq>
I should, but I wasn't. :-)
bittin has quit [Read error: No route to host]
bittin has joined #wayland
bittin has quit [Read error: No route to host]
bittin has joined #wayland
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
immibis has quit [Read error: Connection reset by peer]
immibis has joined #wayland
rgallaispou has joined #wayland
rgallaispou1 has quit [Ping timeout: 480 seconds]
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #wayland
shankaru has quit []
tlwoerner_ has quit []
tlwoerner has joined #wayland
hergertme has quit [Remote host closed the connection]
zebrag has joined #wayland
bittin has quit [Read error: No route to host]
eroux has quit [Ping timeout: 480 seconds]
fmuellner_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
eroc1990 has joined #wayland
neonking has quit [Remote host closed the connection]
alarumbe has joined #wayland
neonking has joined #wayland
wahfato has quit []
wahfato has joined #wayland
<blathijs>
Isn't the point of UI rescaling (making things look bigger for elderly people, or also making things look bigger on hidpi outputs) that the compositor will actually tell clients their windows/surfaces are/should be/can be smaller (less logical pixels), so UI elements become bigger relative to the total window size? And then the second part of this is the wl_output.scale (or surface
<blathijs>
scale in the proposals) that tells the client again that the logical pixels do not correspond to physical pixels, so the client can submit a buffer with more physical pixels than logical pixels, to allow 1:1 copying onto the output (and if the client does not submit more pixels, the compositor will have to upscale the "smaller" window to the real window size in physical pixels).
<blathijs>
That's at least how I understand it, and how I believe UI scaling and resolution are in fact still somewhat separate.
<blathijs>
Also, hi! :-)
<kennylevinsen>
Note: Buffer scale is about making logical pixels correspond to physical (in the simplified case, the VR use-case is different). Output scale on the other hand controls how many logical pixels there are per physical pixel, and is basically 100% user preference.
<kennylevinsen>
it is true that the content of UI and the size of the buffer are technically separate, but the question is whether there is a need to control them independently as they're *almost* entirely identicaly: the only real difference is whether the surface size changes in tandem.
eroux has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
neonking has quit [Remote host closed the connection]
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
bittin has quit [Read error: No route to host]
bittin has joined #wayland
bittin has quit [Read error: No route to host]
bittin has joined #wayland
eletrotupi has quit [Remote host closed the connection]
clever has quit [Ping timeout: 480 seconds]
bittin has quit [Read error: Connection reset by peer]
bittin has joined #wayland
<kennylevinsen>
do we have an "official" definition of what the wl_keybaord modifier bitmask should contain? weston has 6 modifiers, wlroots has 8, mutter adds "virtual" modifiers on top
c7s has quit [Quit: c7s]
c7s has joined #wayland
eletrotupi has joined #wayland
fmuellner has joined #wayland
bittin has quit [Read error: Connection reset by peer]
eroux has joined #wayland
shankaru has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
bittin has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
kindablue has joined #wayland
eroux has joined #wayland
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eletrotupi has quit [Quit: Bye]
hergertme has joined #wayland
<emersion>
it's pretty much keymap-specific AFAIK
<emersion>
juste like keycodes don't mean anything without a keymap
<kennylevinsen>
but compositors hardcode the bitmask?
<kennylevinsen>
just... to different things
<kennylevinsen>
ah wait I'm reading stuff wrong here
eroux has joined #wayland
<kennylevinsen>
d'oh, was mixing up weston and wlroots own internal modifier tracking and what we sent to clients
<kennylevinsen>
but mutter and gtk send "extra" stuff
bittin has quit [Read error: Connection reset by peer]
<kennylevinsen>
kindablue: my misreading aside, wlroots and weston agree and "just" send the xkb modifiers across. Mutter seems to add the bonus modifiers that you are seeing but I'm not really sure what that's about
<kennylevinsen>
maybe jadahl knows the reasoning behind the behavior in mutter?
<jadahl>
kennylevinsen: the modifier? I have to relearn that part everytime, and long enough since I relearned it last time to remember why it exists and what it's for
<jadahl>
maybe there is a bug about it, lets see
<kindablue>
kennylevinsen: okay then. It seems like they adopted it to make gtk integration simpler?
<daniels>
and making it easier for GTK to implement its old semantics wrt consumed/preserved modifiers whilst doing shortcut handling
duxsco has quit [Quit: duxsco]
lxsameer3 has joined #wayland
<daniels>
('related to' as in, xkbcommon didn't always have that mode, and before it did GTK had to do some painful workarounds)
<kennylevinsen>
daniels: thanks for the info
<kennylevinsen>
This all stems from kindablue observing different modifier behavior on mutter and sway with respect to those extra virtual modifiers...
bookworm_ has quit []
<kennylevinsen>
I'll have to figure out how to test this...
bookworm has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
<kindablue>
kennylevinsen: not sure if you found something suitable, but this is what I've been using https://0x0.st/ocCU.txt
<kennylevinsen>
kindablue: I rather meant a way to figure out what this is *supposed* to do and how to trigger it, rather than just looking at what mutter's workaround is doing
<kennylevinsen>
"One of the most troublesome parts of XKB, virtual modifiers appear prominently in all standard keymaps, despite being a relatively minor and mostly useless feature."
rv1sr has quit []
<kennylevinsen>
eh it'll have to wait till tomorrow. If I remember.
<kindablue>
ah fair enough. thanks for helping me out and having a look at it.
<kindablue>
i still don't really follow whether or not this is a bug that needs to be solved. everything i've read stated the virtual modifiers are optional/convenient.
<daniels>
indeed, and looking at the gtk client-side code, it does seem to go to pretty decent lengths to try to turn real modifiers into virtual modifiers
<kennylevinsen>
yeah seeing this discussion stems from a client switching from mod4 to a "super" virtual modifier that only works on mutter, maybe the right answer is "don't do that"
<kennylevinsen>
But knowing nothing at all about virtual modifiers I didn't want to arrive at a premature conclusion
<daniels>
mutter is the only compositor which will send virtual modifiers as part of the wl_keyboard modifier event, but it looks like gtk still tries to deduce what the virtual modifiers might have been if the compositor doesn't provide it, and add it to the event it gives its client
<kennylevinsen>
*should* other compositors send virtual modifiers in the modifier event?
<daniels>
I don't think so, no
<daniels>
it's not necessary; if clients care about them, then they can divine them like GTK does (or at least, tries to)
* kennylevinsen
appreciates that daniels has already sacrificed all the necessary goats to understand all this as he is low on goats himself
<kennylevinsen>
That's good enough for me
danvet has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.4]
d_ed has quit [Quit: Konversation terminated!]
c7s has quit [Ping timeout: 480 seconds]
spstarr has quit [Remote host closed the connection]
hardening has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
u0 has joined #wayland
<u0>
Hello. Can I use graphical apps like zathura from tty without DE? Or I need desktop?