ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Narrat has quit []
garnacho has quit [Remote host closed the connection]
RAOF has quit [Read error: Connection reset by peer]
RAOF has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
Company has joined #wayland
yura has joined #wayland
<yura>
hello
<yura>
Is there anyone alive?
yura has quit []
klausvalka has quit [Remote host closed the connection]
Brainium_ has joined #wayland
Brainium_ has quit []
garnacho has quit [Ping timeout: 480 seconds]
Brainium has quit [Ping timeout: 480 seconds]
silverpower has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
cvmn has quit [Remote host closed the connection]
caveman has joined #wayland
systwi has joined #wayland
caveman has quit [Remote host closed the connection]
<pq>
but since filtering is implementation specific, it only applies to Weston
garnacho has joined #wayland
<pq>
One of the two intentions of wp_viewport is source cropping. Indeed, if the source rectangle was taken in the most strict sense of "no accessing pixels outside of it", it would cause glitches when the source rectangle smoothly slides over the buffer.
<pq>
I think there is also the question: is the top-left corner of a buffer at position 0,0 pixels or -0.5,-0.5 pixels? I.e., is the center of a pixel at x.0, y.0 or x.5, y.5? I don't remember the answer.
<pq>
given that src_x,src_y cannot be negative, I guess the pixele middle is at x.5, y.5.
rasterman has joined #wayland
* mclasen
wonders how alpha multipliers interact with cursor shapes
<pq>
What's the question?
<mclasen>
cursor shape lets you specify surface content compositor-side
<mclasen>
alpha modifier lets you tell the compositor to tweak buffer contents
<pq>
ok, so you wonder if alpha multiplier should be ignored or applied. Or maybe an error?
<mclasen>
I just wondered because as usual alpha modifier spec pretends that you can apply this to an arbitrary wl_surface
<pq>
we certainly can
<pq>
should we, that's the question
<mclasen>
all these protocols interact in unknown ways and create dozens of cornercases. such fun
<pq>
at least we can look at those corner cases and decide the best resolution for the combination
<mclasen>
I was disappointed the other day that mutter doesn't let me use a viewporter on a cursor
<mclasen>
the protocol pretends that should be a-ok to do
<pq>
Thanks to protocol being more descriptive than prescriptive. Prescriptive parts tend to cause the most problems, it seems.
<mclasen>
if you want to be interoperable...
<pq>
it certainly is ok to do
<pq>
also sub-surfaces on cursor surfaces are ok
<pq>
or did that get amended, I forget
<pq>
you can also use a dmabuf, wl_shm buffer, or a single-pixel buffer on a cursor surface
<pq>
you will be able to set a color profile on a cursor
<pq>
etc.
<mclasen>
I can, but whether it works depends on how my compositor decided to apply common sense
<pq>
yes, that goes with all software
<davidre>
mclasen How would you apply alpha-multiplier to cursor-shape
<emersion>
cursor-shape has no surface
<davidre>
You do not have a surface handle with cursor-shape
<pq>
ooh, that's good
<davidre>
the viewpointer issue, sounds like a mutter issue if it's actually allowed
<davidre>
Although I have no other idea if other compositors handle it properly
<mclasen>
ah, right. I had the wrong mental model of how cursor shape operates
<MrCooper>
mclasen: it's just a mutter bug which needs to be fixed
<pq>
There are no restrictions whatsoever on what kind of wl_surface a wp_viewport can be applied to.
<pq>
mclasen, btw. what roles/hats do you wear nowadays? I've been under the impression you had some significant role at Red Hat and/or GNOME? Or GTK?
<mclasen>
I manage some people and I write some code. Not sure if either of those are very significant
<pq>
ok, thanks
fmuellner has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
<Company>
pq: mclasen and me are the 2 main GTK developers atm who (try to) keep track of everything going on - though certain parts of the code have their own experts, like jadahl knows a bunch about the Wayland backend and garnacho knows about input
<Company>
that's more or less the relevant people for GTK / Wayland interactions I think
kts has joined #wayland
manuel_ has joined #wayland
<garnacho>
we talked in the past about splitting gtk/mutter in terms of governance, perhaps next meeting might be a good first
<pq>
Company, cool, thanks
<Company>
technically that might make sense because the POV of the toolkits/apps is often different than the one of compositors
<Company>
but practically I don't know if anyone wants to do that job
<kennylevinsen>
it of course doesn't make extra staff appear out of thin air, but yeah it makes sense
<Company>
like, I try to stay out of the whole protocol mess, because the issue tracker discussions require way too much time
<Company>
and I'd probably get annoyed at the level of bikeshedding
mclasen has quit [Quit: mclasen]
iomari891 has joined #wayland
mclasen has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
mort_28 is now known as mort_
iomari891 has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #wayland
Brainium has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
Guest4684 has quit [Remote host closed the connection]
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest4770
Guest4770 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest4771
Guest4771 has quit [Remote host closed the connection]
<zzag>
davidre: mclasen: fwiw kwin allows using a viewporter on a cursor surface
<mclasen>
excellent
cool110- has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
<pq>
weston does too btw - not that I've tried, but the architecture is completely oblivious whether something a cursor surface or not.
<pq>
*something is
<ifreund>
pretty sure wlroots does as well
kts has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
<leecommamichael>
Hello, I was curious about the wayland.xml used to generate the client-protocol. Why? Is this done to make the protocol more language-agnostic? When should I re-generate the protocol? Should this be done on the user's machine if possible?
<leecommamichael>
(This is with respect to writing a client)
fmuellner has quit [Remote host closed the connection]
rv1sr has joined #wayland
fmuellner has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<kennylevinsen>
leecommamichael: yes, the protocol specification is meant to be human readable and to generate implementations
cool110- has quit [Remote host closed the connection]
<kennylevinsen>
libwayland has its own code generator (wayland-scanner), but equivalent ones exist for other languages and libraries
<kennylevinsen>
think of Wayland like HTTP, with many implementations of servers and clients all speaking a common language defined in a spec.
<kennylevinsen>
When writing a client in C for example, you usually get the core protocol through libwayland itself, while you might have a meson rule to generate other chosen protocols at compile-time
cool110 has joined #wayland
cool110 is now known as Guest4778
<leecommamichael>
kennylevinsen: Right, I was just following wayland-book.com, and it didn't mention what considerations to make for breaking versions. Like, I can try to keep my libwayland-dev ahead of a user's, and re-generate my headers frequently. I read something about the protocol being fairly backwards compatible.
<kennylevinsen>
The protocol is versioned, and so a newer client can speak to an older server and vice-versa, as long as both respect the negotiated version number