ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
lyudess has joined #wayland
Lyude has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
gfxstrand has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
fmuellner has quit []
fmuellner has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Company has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
<DodoGTA>
Is it possible to prevent weird mouse position jumps when relocking the pointer?
rasterman has joined #wayland
mvlad has joined #wayland
Leopold_ has quit []
Leopold_ has joined #wayland
Leopold_ has quit []
rasterman has quit [Quit: Gettin' stinky!]
Leopold has joined #wayland
<MrCooper>
Company: can you pastebin the output of wayland-info?
<MrCooper>
FWIW though, I don't get any float formats advertised by wl_drm either, but vulkaninfo does list FORMAT_R16G16B16A16_SFLOAT for VK_KHR_wayland_surface; presumably zwp_linux_dmabuf_v1 is used
<MrCooper>
wayland-info is identical to mine WRT formats
<MrCooper>
smells like a Mesa Vulkan driver issue to me
cool110 has quit [Ping timeout: 480 seconds]
chiang has joined #wayland
cool110 has joined #wayland
<MrCooper>
Company: actually I can reproduce with Mesa 23.1, looks like it's been fixed on the main branch since then
<rahl>
Do any of the libinput devs hang out here? I'd rather help to fix/improve my touchpad config for the community, rather than e.g. installing synaptic (assuming that would fix the issue)
<pq>
rahl, yes, they do, e.g. whot, but timezones.
<rahl>
The only thing that stands out to me, as with libinputs output, are the dimensions
<rahl>
pq: It seems correctly recognised as a touchpad at least
<pq>
that info looks fine to me
<rahl>
even the width/height?
<pq>
it's set - it's only about scaling the coordinates
<pq>
maybe a wrong number, but not zero and not huge
<rahl>
ah, ok
<pq>
maybe it's about which evdev events the devide node claims to be able to emit, then
<pq>
I'm just guessing here.
<rahl>
How might I check your hypothesis?
<pq>
there are tools, but I forget...
<rahl>
no worries, I'll have a read around. Appreciated
<rahl>
I'm now looking into udev to see if there's a way to probe the raw device. I'd read somewhere and tried `hexdump /dev/input/eventX` and got nothing at all
<pq>
well, it's possible that something already opened the device and took exclusive access to it, so I'm not sure if you'd get a permission denied in that case or just silence.
<rahl>
Cheers for the link - checking
<rahl>
I at least know the touchpad can work, as the originally installed Pop!_os behaved fine
<rahl>
How can I test the keyboard de/activate function keys? Like the one for the touchpad.
<rahl>
That's ACPI stuff right?
<pq>
might be, I dunno
<rahl>
Also, as of yesterday, list-devices shows the touchpad, measure gets no input, debug-events gets no input
<MrCooper>
emersion: ^ might backporting that to 23.1 make sense?
<emersion>
i don't think so, it's not a bugfix, it's a new feature
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
chiang has joined #wayland
chiang has quit []
fmuellner has joined #wayland
ahartmetz has joined #wayland
pochu_ has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
Arsen has quit [Quit: Quit.]
iomari892 has joined #wayland
Arsen has joined #wayland
<emersion>
jadahl: can you explain the use-case with the compositor denying the security context altogether?
<emersion>
i'm not sure i'm understanding properly in which situation that'd happen
<jadahl>
emersion: denying sockets given app IDs is one, sanity checking metadata so the compositor knows it can handle it properly could be another, but I guess it's more about theoretical use cases with a trivial future proofing of the protocol
<emersion>
ideally the sandbox engine would not create sockets if the app is not allowed to do Wayland
<jadahl>
for example if someone tries to use "flatpak" without all the flatpak metadata being there, it'd be an error that is hard to report atm
<emersion>
if the metadata is incorrect per the engine, maybe send a protocol error?
<jadahl>
that's a good point
<jadahl>
(protocol error)
<jadahl>
maybe an error enum for that is enough
<jadahl>
an 'invalid_data' or something
<emersion>
if it turns out we really need a done event, it can easily be added later
<emersion>
added that error
<jadahl>
sure
mort_5 is now known as mort_
<jadahl>
one problem with using an error is that the sandbox launcher must run indefinitely to discover, as disconnecting means it looses it
<jadahl>
but maybe it doesn't matter, if validation fails, it'll be noticable anyway, eventually
<emersion>
validation would happen synchronously no?
<emersion>
flatpak does a wl_display_roundtrip() to make sure the request has been received by the compositor
<jadahl>
no, we try hard to avoid any sinc i/o on the main thread where wayland happens
<jadahl>
*sync
<emersion>
i mean, synchronously when handling the commit request
<emersion>
which would be enough for wl_display_roundtrip() to catch the error
<jadahl>
validation would mean checking if the instance ID is actually there, for example
<emersion>
ok
<jadahl>
so it'd be commit() -> do file I/O async -> on_finished() { accept(); }
<emersion>
i'm not sure this edge case is worth the protocol addition
<jadahl>
so failure would not be detected until the app tries to connec
<swick[m]>
I'm not sure second guessing what the client provides makes sense at all
<jadahl>
yea, it's a bit unnecessary perhaps, the only benifit I see is the sandbox launcher knowing it'll fail, compared to the sandbox app failing