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
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
hexhive has joined #wayland
boistordu_ex has quit [Remote host closed the connection]
Serus has quit [Read error: Connection reset by peer]
Serus has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
tlwoerner_ has joined #wayland
tlwoerner has quit [Ping timeout: 480 seconds]
tlwoerner_ has quit []
tlwoerner has joined #wayland
leon-p_ has quit []
Lucretia has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
slattann has joined #wayland
slattann has quit []
slattann has joined #wayland
bittin has joined #wayland
slattann has quit []
Lucretia-backup has joined #wayland
Lucretia has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
dcz_ has joined #wayland
alan has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
Lucretia-backup has quit [Read error: Connection reset by peer]
ppascher has quit [Ping timeout: 480 seconds]
hendursaga has quit [Ping timeout: 480 seconds]
alan has joined #wayland
ppascher has joined #wayland
pnowack has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
slattann has quit []
slattann has joined #wayland
txtsd has quit [Ping timeout: 480 seconds]
alan has quit [Remote host closed the connection]
rasterman has joined #wayland
jgrulich has quit [Remote host closed the connection]
danvet has joined #wayland
<pq>
codecolla, you could also read the other appendix that docs the C API rather than the protocol in generic terms.
<emersion>
pq, doesn't include protocol docs it seems
<pq>
...oh wait, we don't generate those docs into the book :-/
pnowack has quit [Read error: No route to host]
<emersion>
yea
<pq>
but they are in the (generated) header
jgrulich has joined #wayland
slattann has quit []
<pq>
sometimes I wonder about writing new C bindings generator to bypass libffi completely and with full type-safety as far as possible on both server and client APIs, but why bother and I have better things to do.
<pq>
also hide the proxy-wrapper dance behind another generated function one could choose to use
<emersion>
hm why do we have libffi again?
<pq>
to not generate dispatching switch-case statements into .c
<emersion>
that last part may be implementable with the current API
<emersion>
hm
<pq>
or more likely, it seemed like a cool trick, I guess
<pq>
the main goal was to call registered callback functions that need message-specific signatures
<pq>
yeah, a lot could be added to the current generator
<pq>
libffi-based C dispatch was there long long before the alternative API for generic language bindings was invented that would allow bypassing libffi
slattann has joined #wayland
agd5f has quit [Remote host closed the connection]
agd5f has joined #wayland
slattann has quit []
d_ed has joined #wayland
slattann has joined #wayland
hardening_ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
* ifreund
is very glad the alternative API was invented
jgrulich has quit [Remote host closed the connection]
weylkesiq has quit [Remote host closed the connection]
weylkesiq has joined #wayland
gryffus has joined #wayland
luna_ has joined #wayland
gryffus has quit []
peeterm_ has quit [Ping timeout: 480 seconds]
luna_ has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
lucasmsoares96 has joined #wayland
lucasmsoares96 has quit []
lucasmsoares96 has joined #wayland
flibitijibibo has joined #wayland
rgallaispou has joined #wayland
lucasmsoares96 has quit [Quit: Konversation terminated!]
lucasmsoares96 has joined #wayland
<lucasmsoares96>
Hey guys. How do I develop a native app for Wayland? I mean, without using any widget toolkit. For Xorg I know about Xlib but I haven't found anything equivalent for Wayland.
<kennylevinsen>
lucasmsoares96: using libwayland-client
<lucasmsoares96>
Perfect! Thanks a lot for the help kennylevinsen
lucasmsoares96 has quit [Quit: Konversation terminated!]
lucasmsoares96 has joined #wayland
lucasmsoares96 has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
slattann has quit []
xexaxo has quit [Ping timeout: 480 seconds]
bittin has quit []
<Lyude>
emersion: btw, what other compositors support layer-shell other then sway?
lucasmsoares96 has joined #wayland
<emersion>
Lyude: everything wlroots, kwin, mir
<Lyude>
emersion: I will try to talk to some of my gnome folks and ask more about this, this seems like something that shouldn't really be that controversial
<emersion>
ah, thanks for this
<Lyude>
emersion: did they ever mention any reasons why btw?
<emersion>
hm, i think it's more of a philosophical one, just like CSD
<emersion>
there are some other points, like security, but it's not the first protocol to have security implications
lucasmsoares96 has quit [Quit: Konversation terminated!]
lucasmsoares96 has joined #wayland
<emersion>
but i don't want to speak for them :)
<emersion>
ultimately, it comes down to "do we want our compositor UI elements to be swappable?"
<emersion>
also… GNOME historically *needs* to draw everything in their main process, because the way it's been designed
<emersion>
GNOME extensions and all of that
<emersion>
changing this is non-trivial
<Lyude>
ahh, good point
d_ed has quit [Ping timeout: 480 seconds]
<ebassi>
At most, we discussed adding support to GTK for creating wayland shell components; but that work is blocked on a large refactoring of the wayland backend in GDK
<Lyude>
it seems like it's a maintanence thing as well (just talked w/ some gnome folks, I've been quite curious) and that it's mostly just not a priority and would need someone willing to work on it/maintain it
<Lyude>
ebassi: yeah that makes a lot of sense, I assume GDK has changed quite dramatically since the g-s 3.1x days but I remember there being a loooooot of code that seemed like it only assumed X
<ebassi>
GDK4 is closer to wayland than X11, these days
<Lyude>
(back when I was working on wl_tablet for GTK+, which I'm think someone else picked up)
<jadahl>
i don't think security is an issue with input methods, they'd likely only ever be allowed to be launched by the compositor itself
<jadahl>
then there is the problem of surface management, and that needs clearly defined input method roles (popup style, vs osk) so the compositor can special case them
Seirdy has joined #wayland
<emersion>
yes
<romangg>
jadahl: Why would you want to only allow them to be launched by the compositor itself? Wouldn't it be more pluggable/extensible/simpler if the user could just start the input-method client that is preferred?
<jadahl>
romangg: could in theory be a flatpak with some kind of special permission too
<jadahl>
but then the security management is outsourced to flatpak and the compositor would just look at the permission store
<jadahl>
but wouldn't want different "apps" to fight over who can be the keyboard
<romangg>
Yea, I guess it would make sense if the shell process would offer some kind of selection dialog to choose the input method variant (and ensures the previous one is killed before that).
dcz has quit [Ping timeout: 480 seconds]
<romangg>
But then it could still be outsourced from the compositor this way what I think is good.
<jadahl>
or do what android does and hide it away in settings. you tend to only select a keyboard once per install anyway
<romangg>
right
<jadahl>
but thats just permission store and service launching management I guess
<jadahl>
not really something a compositor have to care about
<jadahl>
it just needs to check, and be angry/happy
<jadahl>
my point is mostly, an input method protocol can concentrate on input methods, it doesn't necessarily need to deal with permission, it's rather orthogonal to it
<emersion>
yeah, agreed
<jadahl>
Lyude: btw, gnomeshell doesn't (and don't intend to) support third party panels etc, which is why layer shell isn't and thing in gnome shell
<jadahl>
but input methosd sholudn't need that really, if that was the context to that question
<Lyude>
jadahl: yeah - the layer shell thing seems reasonable not to want
Krner[m] has joined #wayland
<Lyude>
it had just been mentioned that I think some OSKs use layer-shell
<jadahl>
i know "virtual keyboard + layer shell" is something people do, but it's not a proper input method solution imo
<jadahl>
right
<jadahl>
it's the X11 style of an OSK :P
<Lyude>
yeah, I was just thinking it seems like those two things shouldn't need to depend on eachother (or if they did, it feels like layer-shell could do with being split apart so there's a protocol with only the bits virtual keyboards actually would benefit from
<romangg>
It feels not bad on first sight to use layer-shell for vks. The vk knows best what kind of use pattern it does provide. What's speaking against it?
<Lyude>
I was moreso talking about the fact that it seems like layer-shell might get hesistance in general if it's such a widely applicable protocol. but-don't listen too much to me because I haven't read through layer-shell myself
<jadahl>
romangg: the osk knows about itself, but it doesn'n know how to position itself, it doesn't know how to position other clients's windows, it doesn't always know when to get lost, or when to appear, or in what way. in gnome-shell, it's not ever clean whether an arbitrary "layer" is visible at certain points
<romangg>
jadahl: Can't say much about gnome-shell's specifics :) but the compositor of course can still validate and manipulate the stuff the osk sends. There would also maybe the option to add a specific layer to the layer-shell protocol for things that "vk-like", so the compositor has even more information about what this layer is.
<romangg>
But emersion could say more about that.
<romangg>
*for things that are "vk-like"
<jadahl>
romangg: still, imo makes no sense to put something very particular, that needs careful compositor coordination, into a generic protocol used placing panels and notification bubbles etc. even if one can "derive" that its an OSK using various hints if one knows where to look
<emersion>
jadahl: last time i looked we wanted to add a input-method request to indicate the surface. with that layer-shell is a very good fit
<romangg>
emersion: how would this work exactly?
<jadahl>
emersion: iirc the input method protocol we have already have some kind of "role" like thing for the surface
* romangg
do not understand yet :P
<romangg>
jadahl: only for popups though. could be expanded with another role for vk surfaces. but it would be nice to keep the size of next input-method protocol small.
<romangg>
jadahl: my feeling is some vks might need to provide more info than just the role plus its size. for example you might have a one-hand-mode vk which should be positioned in one of the corners. Another vk should be positioned in the middle instead.
<jadahl>
romangg: i'd more expect an osk im receives its size as a configure event just like xdg-shell
<emersion>
what if there are two surfaces, one per hand?
<jadahl>
with a "supported_types(arra)" event so one doesn't end up forcing smart phone sized views to squeeze in two keyboards in one tiny screen
<jadahl>
(well, thats the first thing that comes to mind anyhow)
leon-p has joined #wayland
<jadahl>
romangg: btw, is there any thoughts in the text-input side of things to let clients decide whether to *resize* or *overlap* with an OSK? as in, when an OSK shows on top of a window, does it resize or just get an OSK on top? android does this and it's pretty good thing to let applications decide
<jadahl>
(its too much of a wall of text to parse this late, sorry for not looking at the issue)
<romangg>
np
<romangg>
hmm, I don't think there is at the moment. But it's definitely something that should be communicated somehow. But should it be part of the text-input protocol?
lucasmsoares96 has quit [Ping timeout: 480 seconds]
<romangg>
Yea, makes sense to let the text-input client tell the compositor about it.
<jadahl>
it probably needs to, since its the owner of the UI that receies the text that knows that
<emersion>
there's a discussion about that somewhere
<jadahl>
e.g. two examples I tested on my android now: a Im client, text box at the bottom. the osk shows, the window is resized so the text box is above the osk
<jadahl>
another app, the text box at the top, osk shows up, no resizing, text box is still visible while also knowing how far up the osk came
<jadahl>
emersion: as long as it's there somewhere, I'm sure it'll be remembered :P
<emersion>
why not resize?
<emersion>
in the end the part where the OSK is will not be visible
<jadahl>
iirc when I worked on android ~10 year ago, one reason was that resizing resulted in minor glitches because resizing wasn't instant enough
<jadahl>
worked on an android 8app*
<jadahl>
not android itself
<emersion>
that… doesn't seem like a great reason
<emersion>
worst case, use viewporter to crop
<jadahl>
it's only visible while the keyboard animates away
<jadahl>
anyway, thats how android works (still, today)
<emersion>
only start the animation when the client has sent a new buffer
<emersion>
this is no different from an interactive resize
<jadahl>
well, for a client it is, it'd need to special case "osk resize" to just cut things off. seems easy with viewporter anyhow, but not resizing anything I imagine is the common case on a laptop-with-touchscreen like setup
<romangg>
osks on laptop with touchscreen setup plus floating window manager is a special case of complicated it feels. :D
<romangg>
I would think doing a resize would work there best though.
<romangg>
but yea, somehow the client with text-input focus should be informed that the resize is because of some input-method needing the space.
<jadahl>
the osk on a laptop is a bit special yea :P
<codecolla>
But I might be wrong on how to transmit user data in a callback
<codecolla>
I compile this way : gcc -Wall -g -o wayland_shm wayland_shm.c -lrt -lwayland-client;rm /dev/shm/Wayland;valgrind ./wayland_shm
<codecolla>
Can someone say me where am I wrong?
<kennylevinsen>
codecolla: you need two buffers - you're not allowed to touch a buffer while it is being displayed, and it will be displayed at the very least until you send a new one.
<kennylevinsen>
you need to wait for wl_buffer::release before you're allowed to touch it again
<kennylevinsen>
rendering to your front buffer is not allowed and will lead to glitches
<codecolla>
Ok, so I'm gonna double buffer pointer and give a new try. in seconds
<kennylevinsen>
codecolla: you need to wait with your wl_surface_commit till *after* you set up the frame callback. The callback is double-buffered state, so it won't apply till you commit. :)
<codecolla>
I did it with only one buffer, and it was working, but may leaded to some glitches
d_ed has joined #wayland
<codecolla>
Near line 99, I commit
<kennylevinsen>
yeah it'll show stuff, but unlike in X where it's just not great, it's actually flat out a bug in the application and violation of protocol to do it in wayland. When you send a buffer to the compostor, you're completely disallowed from touching it until it's released back to you
<kennylevinsen>
codecolla: yeah, but you commit BEFORE you setup the new frame callback
<kennylevinsen>
you need to commit *after*
<kennylevinsen>
it's not registered till you commit
<codecolla>
Ok, not sure to get all the picture, but the first thing to do seems to make it double buffered, right?
<kennylevinsen>
the main bug you're having is that you're committing too early
<kennylevinsen>
that's why you don't get any events
<kennylevinsen>
move wl_surface_commit till the end of draw_frame
<codecolla>
Hoooo ok, add listener goes to the queue, I need to commit once that done...
<codecolla>
segfault, lol, I investigate
<kennylevinsen>
actually it's wl_surface_frame that goes to the queue to request the event - wl_callback_add_listener just sets locally what you want to do when receiving the event