ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
melonai0 is now known as melonai
Serus has quit [Ping timeout: 480 seconds]
Serus has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
tent405 has joined #wayland
jmdaemon has joined #wayland
nerdopolis has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Remote host closed the connection]
iomari891 has joined #wayland
<Nosrep>
because the registry's global_remove event only gives a uint32_t, do i have to keep track of the name myself (and do i even need to handle global_remove? wl-clipboard looks like it doesn't)
<danieldg>
you don't have to, no
<danieldg>
you can also just track the id of any resources you bind
<danieldg>
remove is mostly only for outputs and seats, if you don't use those you don't care
<Nosrep>
ic
<Nosrep>
then ill probably just track the name of the seat (or copy wl-clipboard and not care :x)
<danieldg>
wl-clipboard is short-running; removals mostly only matter for long-running things
carlos_ has quit [Ping timeout: 480 seconds]
<Nosrep>
wl-paste has a watch mode, but idk if that uses a different listener? i dont think so though
<danieldg>
no, that one is longer-lived but not really meant to be 'forever'
<danieldg>
though if you use it as a daemon I guess it does live long enough that it should handle removals
iomari891 has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
<Nosrep>
so let's say the wl_seat gets removed or something, do i have to destroy the zwlr_data_control_device too or will it call finish itself or something?
<danieldg>
you should destroy it just to free the id; it might fire finish for you, though
<Nosrep>
aight thanks
Guest6394 has joined #wayland
Guest6394 has left #wayland [Konversation terminated!]
gallo has joined #wayland
julio7359 has joined #wayland
sima has joined #wayland
sima has quit [Remote host closed the connection]
sima has joined #wayland
Company has quit [Quit: Leaving]
tent405 has quit [Quit: tent405]
julio7359 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
<emersion>
mstoeckl: thanks for trying to simplify the buffer size control MR
<emersion>
last time i looked, i just didn't understand it fully
mvlad has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
rasterman has joined #wayland
iomari891 has joined #wayland
<pq>
cambrian_invader, if you don't use --log argument to weston, it prints all logs to stdout/err. Maybe your systemd service unit discards that somehow, or maybe the logs get associated with a unit you did not expect? Are you sure 'weston' is an actual binary and not a script messing with the output redirection?
tent405 has joined #wayland
tent405 has quit []
<pq>
cambrian_invader, maybe the logs go to the user journal, not system journal?
<narodnik>
for the keyboard listener event keymap, do I really need to use mmap in rust, thus forcing me to load libc in my code?
<emersion>
mmap is a system call
<emersion>
you don't necessarily need libc to do that
<emersion>
although my understanding is that the Rust stdlib uses libc
<narodnik>
yeah i still need to manually load it in my user code
<narodnik>
so i can access mmap
<emersion>
you can just do the syscall
<narodnik>
not possible without adding an external library
<emersion>
you don't need any external lib do perform a syscall
<narodnik>
well i then need some assembly code, right?
<narodnik>
or how would i do that
<emersion>
i would hope that at least a crate exists for this
Lucretia has quit [Read error: Connection reset by peer]
<emersion>
with Go, you would be able to just compile with CGO_ENABLED=0 to get this behavior
<emersion>
anyways, this dives into a Rust discussion not really related to Wayland
<pq>
narodnik, I believe "mmappable" is a stricter requirement than "readable", so I think using read system calls should be fine too, as long as you avoid relying on the file offset property of the file description.
<pq>
I don't know why simply reading wouldn't work.
<emersion>
indeed
<emersion>
use pread over read
<pq>
I have no idea how that translates to Rust though.
<pq>
I'd expect Rust APIs to not rely on the shared file offset to begin with.
<pq>
but I don't know
Lucretia has joined #wayland
<emersion>
pq, be it mmap or read, i think the Rust stdlib just calls libc
<pq>
but pread vs. read?
<emersion>
i don't know how/if the stdlib exposes this
<pq>
I'd expect read without p to not be exposed at all
<narodnik>
pq, emersion: it's fine, I will use libc library for mmap
<narodnik>
i realized it's already being used in my ffi bindings for wayland
<vyivel>
can xdg_popups be remapped? afaiu, an xdg_surface must ack a configure event before committing with a buffer attached, and mutter/kwin seem to never send one to an already unmapped popup; however, if xdg_popup.reposition is sent, weston and anvil(smithay) reply with a configure event anyway, which technically allows the xdg_popup to map again
<vyivel>
unless i'm mistaken, xdg-shell doesn't really forbid remapping xdg_popups, but then mutter/kwin behavior seems strange
<vyivel>
xdg_popup.reposition description states that "a xdg_popup.repositioned followed by xdg_popup.configure and xdg_surface.configure will be emitted in response", regardless of whether the xdg_popup is mapped
<jadahl>
vyivel: the only way to map a popup is xdg_surface.get_popup(). you should be able to remap the same wl_surface by recreating that role
<emersion>
jadahl: what about attaching a NULL buffer to unmap, then doing an initial commit?
<jadahl>
emersion: only meant to work with xdg_toplevel IIRC
<jadahl>
get_popup()+grab() needs a serial
<emersion>
right, but that would be without a grab
<jadahl>
seems only xdg_toplevel defines what happens if you attach null
i509vcb has quit [Quit: Connection closed for inactivity]
<jadahl>
iirc when this was designed, the conclusion was that xdg_popup was not remappable without a new get_popup, but xdg_toplevel could be.
<jadahl>
this was discussed during the time when we decided whether to allow attach(null) at all
<vyivel>
so, a compositor should (try to; it's racy anyway) never send configure events to a popup that has been mapped and unmapped, and the client must never remap it, right?
<jadahl>
thats my interpretation - only send a configure to an unmapped popup in response to get_popup
<vyivel>
a configure isn't sent in response to get_popup, that would be too early
<vyivel>
it's sent in response to an initial commit
<jadahl>
sure, I mean on a new xdg_popup, not a reused one
<jadahl>
sorry for the confusion
<pq>
what's a good phrase for "B must be after A, and only once after each A" without implying "immediately"?
manuel1985 has joined #wayland
sozuba_ has joined #wayland
sozuba has quit [Ping timeout: 480 seconds]
na[m] has quit [Quit: Client limit exceeded: 20000]
<pq>
What's your favorite toolkit for writing "small" Wayland apps where you also need low-level access to all Wayland details, e.g. get a hand of the wl_surface backing a sub-surface used with OpenGL, and custom protocol extensions?
<pq>
while being able to easily have simple widgets like buttons, sliders, and non-editable text
<emersion>
*crickets*
<emersion>
more seriously, maybe one of these GL mini-toolkits?
<pq>
hmm. Would they let me pick an arbitrary EGLConfig? Particularly 16F.
<pq>
I don't need GUI widgets *in* OpenGL, but I do need one widget that gives me an OpenGL sub-surface to do what I want with.
<pq>
hmm, but GUI widgets in OpenGL could help...
<pq>
right now I'm trying to use Weston's toytoolkit and I find myself reinventing the concept of a "button" from Cairo primitives and wl_pointer events. >_<
<kchibisov>
gui toolkits exposing details is a rare thing I'd say.
<pq>
this was supposed to be a fun side-project, but not *this* fun
<pq>
indeed
<kchibisov>
Like I know that with winit you can do most of it, it'll just take a bit of time.
<kchibisov>
And your custom protocol will be handled on your own, but you have wl_display/wl_surface and such.
<pq>
I imagine the Rust raw_window_handle etc. smithay toolkit ecosystem might come really close, after you bolt ICED widgets on it
<kchibisov>
For your case egui could be more or less what you want.
<pq>
which is something I want to do, but... later
<kchibisov>
if you want to have 1-2 buttons and such.
<pq>
hmm
<pq>
and text?
<pq>
simple text
<kchibisov>
Yeah, very simple text with egui as well.
<kchibisov>
it's like imgui.
<pq>
alright
<kchibisov>
I just know that you can achieve what you want with glutin + winit under like 10-20 mins.
<kchibisov>
If we rule out buttons.
<kchibisov>
Because glutin exposes all the EGL config picking on you.
<pq>
yeah, I've occasionally typing a glutin+winit app at home for a few months now
<kchibisov>
I've been doing that for like 5 years.
<pq>
but I will also be needing direct Wayland access
<kchibisov>
You can do so.
<kchibisov>
You take the display, create a queue out of it and you're good to go.
<kchibisov>
And dispatch the queue inside your `run`.
<kchibisov>
alacritty does that for a long time.
<kchibisov>
Because we needed frame callbacks, and winit has some issues with making them in, so we have our own queue to do what we want.
<pq>
I see
<kchibisov>
So you can do anything you want outside of winit, except when you'd need a reference to e.g. xdg_toplevel or some winit object.
<kchibisov>
(unless it's wl_surface exposed by winit)
<kchibisov>
Though, nothing stops winit from exposing the role objects.
<kchibisov>
Is it similar to what glfw/sdl does? Where it ties the graphics/windowing together, so you have to express the buffer handling and develop pixel formats of some sort?
shankaru has quit [Remote host closed the connection]
shankaru has joined #wayland
<orowith2os>
@kchibisov impressive, and weird
<orowith2os>
Wayland bindings exist for Rust, why is miniquad using the raw stuff? @narodnik
<kchibisov>
orowith2os: dunno, rust has really weird ecosystem wrt windowing.
<orowith2os>
Fair enough
<kchibisov>
It's like everyone knows how to do everything and literally no-one tries to cooperate.
<kchibisov>
So instaed of helping with winit, subpar solutions are borned sometimes.
<orowith2os>
My dive into Smithay showed me that 1. I'm not ready for anything low level, 2. I'm never interacting with the bare windowing system, and 3. I have quite a ways to go in regards to learning to program :p
<kchibisov>
I'm not saying that miniquad is subpar, but the wayland impl they have could be better, if they opted for wayland-rs at least.
<kchibisov>
still simpler than doing raw pointers.
<emersion>
smithay contained quite a lot of magic last time i tried to look
<kchibisov>
smithay yes.
<emersion>
i never managed to wrap my head around it
<kchibisov>
I also have no clue what is going on in it.
<kchibisov>
But the client side is rather simple.
<kchibisov>
And I write clients, so I don't mind what they do on the server.
<orowith2os>
Maybe qtile is more my style, though then I have to learn python :D
<kchibisov>
Though, from what I understood it got better in smithay recently.
___nick___ has joined #wayland
Moprius has joined #wayland
<drakulix[m]>
And I am always happy to mentor people trying to wrap their head around smithay. Not that @emersion has a need to do that. 😅
<emersion>
good to know!
<drakulix[m]>
In general you matrix chat is very active and welcoming. 🙂