ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
systwi has quit [Remote host closed the connection]
<danieldg>
riteo: I expect you treat it like any other surface: request fractional scale, make a viewporter scaled surface, and generally leave the hotpoint alone
Brainium has joined #wayland
<danieldg>
unless something else about cursors is different? They are more likely to need the compositor to scale them when they cross monitors that change scale, I guess
<riteo>
danieldg: shouldn't I also care about the new actual buffer size?
<riteo>
like, if the scaled result is 24 * 1.5 = 36, shouldn't I somehow load the proper theme size?
<riteo>
or should I just cache the biggest size I encountered yet and let it be downscaled?
bim9262 has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
bim9262 has joined #wayland
<danieldg>
if your cursors are bitmaps, then you should probably grab the largest one and let it be scaled, or pick one that is the right size at the moment
co1umbarius has quit [Ping timeout: 480 seconds]
<danieldg>
though I expect a bit of 'how does GTK do it' experimentation may be desired, because it's worse to be inconsistent
<riteo>
I think that they're always rasterized into constant-sized buffers
<riteo>
so if I don't somehow switch the buffers they're gonna get blurry
<danieldg>
yes, you switch the buffers
<riteo>
I suppose that there's gonna be overhead if I reload the theme with a different size every time, isn't there?
<danieldg>
you should really only need to reload it once? I guess you could cache sizes if you wanted to switch back and forth
<riteo>
mh
<riteo>
for some reason I feel like this is very convoluted
<riteo>
like, I blindly cache every size or just load the biggest size I've seen even if I'm not going to see it ever again
<danieldg>
the same is true for everything you draw, really
<riteo>
mhh I see, you're completely right
<danieldg>
fonts, icons, etc
<riteo>
I'm tempted to do what we're already doing with integer scaling, which is, well, keeping only the biggest size we've registered
<riteo>
so on a 1.25 we'd go to 2 directly and downsample it
<riteo>
are there going to be aliasing issues?
<danieldg>
depends on the compositor
<danieldg>
nothing in wayland specifies how scaling is done
<riteo>
mh I see
<riteo>
I'm a bit scared of caching every single size honestly. I'll probably go with the "update only when strictly necessary to not blur into the void for bigger sizes" route
<riteo>
thanks a lot for your clarifications!
<danieldg>
if it's a simple cursor theme it might only have a few (3-4) sizes in the first place, so that's all you could cache
<riteo>
can we even probe available sizes from wayland-cursors?
<riteo>
the API is just "load theme x with size y"
<riteo>
also animated cursors are a thing
<danieldg>
yeah, I basically ignored animation
<riteo>
btw regarding the GTK consistency thing I'll definitely take a look while testing (eventually), but I'm not too concerned since I recall seeing some GTK bug reports regarding frac scale of cursors
<riteo>
might be fixed though, can't recall
<danieldg>
just matching 'how does it handle scale=2' is probably good
<riteo>
uh that's probably already correct
orowith2os[m] has joined #wayland
<orowith2os[m]>
Standardize loading cursors as vector images, that way you don't have specific sizes :)
<riteo>
you still have to rasterize them though :P
<danieldg>
wouldn't that be nice
<danieldg>
sure, but you just reraster on scale changes, that's fairly sane
<riteo>
oh you mean like, client side?
<danieldg>
yes
<riteo>
that would be very interesting
<orowith2os[m]>
I'd imagine not too technically impossible
<orowith2os[m]>
Though a bit painful with animated cursors, like loading
<riteo>
yeah, we'd just have to define a somewhat sane vector format as I don't really see clients embedding a whole SVG renderer :P
<danieldg>
you already do that if your GUI is vector anyway
<orowith2os[m]>
Maybe it could even improve animated cursors? Currently it looks like you store 60 images of one animated cursor and loop over that, if vector formats improve on that, wonderful
<orowith2os[m]>
riteo: sounds like a fun side project I can hack on
<riteo>
That'd be great!
<riteo>
We seriously need better "embedded" vector solutions
<riteo>
heck, vector's the future! I wish there were more vector solutions in general!
<orowith2os[m]>
Toss me your discord, I'd also like to poke you about more Godot Wayland stuff too
<riteo>
oh that'd be great! Although I don't use discord much
<danieldg>
fonts are vector graphics already, so almost everyone has an engine to do that
<riteo>
I'll send that in private. If anyone else wants it, feel free to ask
<danieldg>
the funnier fonts can embed SVG
<danieldg>
and also PNG
<riteo>
mh yeah but most fonts are a bit domain-specific, aren't they?
<riteo>
that's the reason emojis had to get their own format
<riteo>
what was it, woff?
<danieldg>
there are still fonts with emojis
<riteo>
yeah but they embed as you said PNG/SVGs, which aren't really what normal fonts use
<danieldg>
true, but a font rendering engine kinda has to support them still
<riteo>
they're not accessible though. Godot, despite using Freetype/Harfbuzz had to import their own full-fledged SVG library
<riteo>
I think it was ThorVG
<danieldg>
I guess you can decide not to do that and just have the simple font support, which is a vector format but doesn't do colors so not really good enough for cursors
<riteo>
yeah that would still cover like 90% of fonts
<danieldg>
even the most boring cursor is black with white border, which is beyond a TTF file to represent
<danieldg>
making a new cursor format would be quite a long project; you have to get it in all the toolkits plus all the control-panel-type GUIs
<danieldg>
it would be nice to add a way other than dconf to specify a per-seat cursor choice, though
<danieldg>
(actually, can you even do that with dconf?)
<danieldg>
the normal setting is just "org.gnome.desktop.interface cursor-theme" no mention of seat
Company has joined #wayland
<riteo>
it's a bit funny that cursors were all the rage back then and now they're like an afterthought
<riteo>
I recall switching an awful lot of sketchy cursor themes on windows 7 when I was a kid
<danieldg>
windows 3.1 had really cool animated cursors too, so they're pretty old
Brainium has quit [Quit: Konversation terminated!]
<DemiMarie>
I would much prefer for the system to provide a fixed list of cursors and for the client to have to pick one of them. This is an interface that Qubes OS (and other compartmentalized systems) can actually support. Arbitrary client-provided cursors isn’t, so the compositor I am working on for Qubes OS currently ignores the client-chosen cursor.
<orowith2os[m]>
Demi: client-provided cursors wasn't even brought up, I think?
<orowith2os[m]>
the client can provide cursors of their own, but they can't recommend them to other clients
<orowith2os[m]>
this is more for cursors when the client has to draw them
<DemiMarie>
Rika (she/her): in Qubes OS we explicitly do _not_ allow clients to draw arbitrary cursors, because this would allow them to hide the cursor.
<orowith2os[m]>
you can't disallow that, afaik. It's client opt-in behavior
<DemiMarie>
And since this was on #_oftc_#wayland:matrix.org, I assumed that it had to do with Wayland as a protocol, rather than being an implementation detail of a given client
<DemiMarie>
Rika (she/her): clients can set a cursor, but the compositor doesn’t have to use it, and the compositor that I am working on for Qubes OS simply ignores it
<orowith2os[m]>
do the clients have to set a cursor in that way? can they not skip wl_pointer and draw it themselves?
<zamundaaa[m]>
One more reason for all the clients to adopt cursor-shape-v1 :)
<DemiMarie>
Rika (she/her): yes, but that will be more likely to be noticed, or at least that is what I think the theory is
<orowith2os[m]>
my point is more that you simply can't stop a client from "faking" a cursor icon
<DemiMarie>
That said, strong anti-spoofing probably requires tinting all untrusted surfaces or something like that
<DemiMarie>
So that cursors, borders, and other trusted components have a color that no untrusted client can forge
bim9262 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
that seems like tons of unnecessary work, but you do you
<orowith2os[m]>
shouldn't be impossible to implement, in any case
<DemiMarie>
Right now Qubes OS doesn’t do it, and I don’t know if it is needed in any case
<DemiMarie>
Security is Hard 😆
<orowith2os[m]>
unnecessary security is Even Harder :)
<orowith2os[m]>
I doubt manipulating a client-local cursor image matters at all
<DemiMarie>
Ideally this would be determined via human interaction studies.
bim9262 has joined #wayland
<orowith2os[m]>
in any case,
<orowith2os[m]>
issue 166
privacy has quit [Quit: Leaving]
<orowith2os[m]>
do take a peek
<orowith2os[m]>
it sounds like, currently, clients wanting that behavior rely on UB
<orowith2os[m]>
so let's make it defined
<orowith2os[m]>
Demi: what's your gitlab username?
<orowith2os[m]>
nvm, got it
<Company>
playing around with pointer warping and mouse cursor offsets sounds like a fun way to learn information about the system
<Company>
by checking where the user clicks
<Company>
though I suppose it's easier to fake by doing a transparent fullscreen window
nerdopolis has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
kts has joined #wayland
<DemiMarie>
Company: This is why Qubes OS does not support transparency.
<Company>
that's an easy workaround for that stuff at least
<DemiMarie>
Yup
<DemiMarie>
At least my personal expectation is that applications should work on Qubes OS, but some features may be missing.
bim9262 has quit [Ping timeout: 480 seconds]
<DemiMarie>
On the other hand, Qubes OS will require the desktop environment to support layer-shell, so it is expected that some desktop environments cannot be supported.
bim9262 has joined #wayland
kts has quit [Quit: Konversation terminated!]
<DemiMarie>
Company: this is _not_ an anti-GNOME rant, FYI. GNOME being opinionated is perfectly okay, but it does make it unsuitable for Qubes OS.
greg21 has quit [Ping timeout: 480 seconds]
sevz has quit [Quit: WeeChat 4.1.1]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<Company>
DemiMarie: why would you need layer-shell?
<DemiMarie>
Company: Qubes OS has custom desktop environment components and reimplementing them for each supported desktop environment isn’t practical.
<Company>
that sounds like you should just implement a compositor
<DemiMarie>
We don’t have the resources to do that, and besides not everyone will want to run the same compositor.
<DemiMarie>
Better to leave that to the people who actually know how to do that.
<Company>
you can't really enforce no transparency in that case though?
<DemiMarie>
Actually we can, by proxying the Wayland protocol and e.g. replacing ARGB with XRGB.
<DemiMarie>
If it turns out that we do need to write our own compositor, it will be a rootless nested compositor, so we will still need layer-shell support from the desktop environment.
<DemiMarie>
A Qubes-specific user-facing compositor isn’t going to happen.
sima has joined #wayland
<Company>
I would think this is a much more time-intensive approach
<Company>
trying to force external compositors into submission sounds a lot harder than just creating your own one
<Company>
that doesn't do the stuff you don't want to do
glennk has joined #wayland
rv1sr has joined #wayland
Company has quit [Remote host closed the connection]
flom84 has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
privacy has joined #wayland
lockywolf has quit []
lockywolf has joined #wayland
flom84 has quit [Quit: Leaving]
Fxzxmic has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
Fxzxmic has quit [Quit: Konversation exit!]
glennk has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
Fxzxmic has quit [Remote host closed the connection]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
glennk has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
Moprius has joined #wayland
bookworm has quit []
bookworm has joined #wayland
Brainium has joined #wayland
rasterman has joined #wayland
Moprius has quit [Quit: bye]
trclst has quit [Quit: trclst]
kts has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
kts has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Company has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
DodoGTA has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
aknot has joined #wayland
gallo_ has quit [Ping timeout: 480 seconds]
yang3 has quit []
yang3 has joined #wayland
yang3 is now known as yang
Company has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
Brainium has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
gallo has joined #wayland
sevz has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
bim9262 has joined #wayland
fgdfgdfgd has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
fgdfgdfgd has joined #wayland
Company has joined #wayland
glennk has joined #wayland
nerdopolis has joined #wayland
Guest8044 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest8230
tristianc6704 has quit [Ping timeout: 480 seconds]