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
pochu has quit [Ping timeout: 483 seconds]
leon-p has quit []
zebrag has joined #wayland
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
boistordu_old has joined #wayland
mon_aaraj has joined #wayland
mon_aaraj has left #wayland [#wayland]
boistordu has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
mixfix41 has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
dcz_ has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
pochu_ has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
creich has joined #wayland
pnowack has joined #wayland
creich is now known as Guest1363
dcz_ has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
<emersion>
pq: whenever we get enough merged to make a meaningful release. iirc last time i pinged (6 months after the prev one) there weren't enough new stuff
<emersion>
pq, would now be a better time to plan a release?
leon-p has joined #wayland
<punit>
I am hoping somebody familiar with weston / libgbm can confirm if my understanding is correct - in the drm backend, the buffer object returned by gbm_bo_import() for a dmabuf seems to be from the render device rather than the scanout device
<MrCooper>
how do you determine that?
<punit>
Enabling debug, I see the "Failed to lookup object" message
<punit>
as a result of the addFb() ioctl
<punit>
I was wondering if this is a bug in libgbm implementation
<MrCooper>
sounds like you left out a gbm_bo_get_handle step :)
<MrCooper>
the GEM handle returned by gbm_bo_get_handle should be valid for the DRM file descriptor passed to gbm_create_device, otherwise there's a GBM implementation bug
<MrCooper>
e.g. I fixed issues like that in the radeonsi driver amdgpu winsys a while ago
<punit>
I am on an embedded platform - i.MX6 using Etanviv for 3D and imx-drm for display
<punit>
But afaict, for libgbm it seems to be using the kmsro backend.
<punit>
(Apologies for missing terminology - I've only recently been digging into the graphics stack)
<MrCooper>
maybe there are similar issues in etnaviv or kmsro then
<punit>
It does feel like it - at some point, in the gbm_bo_import() implementation, the GBM_BO_USE_SCANOUT seems to be getting ignored
<MrCooper>
that shouldn't matter per se
<MrCooper>
if the BO wasn't scanout capable, addFB would fail differently
<punit>
Oh - I was working with the understanding that the flag indicates the intended purpose of the returned BO
<punit>
Ah I see - so the failure mode should've been different
<MrCooper>
"Failed to lookup object" means the GEM handle isn't valid for the DRM file description
<punit>
Right - the error goes away if we configure off the etnaviv driver (in the kernel)
<punit>
Which I took to mean that for some reason the libgbm implementation is getting confused in the presence of /dev/dri/card0 and /dev/dri/card1
<MrCooper>
sounds like it
<punit>
Thanks - I wanted to make sure I was thinking straight before writing this up to ask for help on mesa-devel
<punit>
Is there an appropriate wayland mailing list that would be appropriate to cc on the report? Since the issue starts off in weston, the devs here might have an opinion...
<MrCooper>
in theory weston could mix up the DRM FDs, but I assume that would have been found by now
<MrCooper>
I'd recommend filing a Mesa GitLab issue; the mesa-dev mailing list is hardly used anymore
<punit>
We did look into that (weston mixing up FDs) but that doesn't seem to be the case
<MrCooper>
yeah, it might not even have more than one FD
<punit>
I didn't realise that gitlab is the way forward - thanks for the heads up
rasterman has joined #wayland
pochu has joined #wayland
pnowack has quit [Read error: Connection reset by peer]
pnowack has joined #wayland
<raghavgururajan>
Hello Folks!
<raghavgururajan>
Does wayland has default terminal emulator, like xterm in X11?
<jadahl>
raghavgururajan: weston-terminal is the most default there is
<jadahl>
as in, it was the first
<raghavgururajan>
I see.
<jadahl>
but it's not really used by many for "daily use"
<raghavgururajan>
sway seems to use alacritty as default.
<jadahl>
there are per-project defaults indeed. I assume KDE defaults to konsole, while GNOME defaults to gnome-terminal
<raghavgururajan>
Yeah.
flacks has quit [Quit: Quitter]
flacks has joined #wayland
<pq>
emersion, I think daniels and maybe mvlad might know better. My head is kinda buried in the CM&HDR sand.
<pq>
raghavgururajan, no, there is no default Wayland terminal. Like there is no one Wayland compositor, either. Even de facto one like Xorg is for X11.
<pq>
raghavgururajan, do you have a reason to care about Wayland in particular?
<kennylevinsen>
I suspect the question was worded wrong, as xterm isn't "default" either, but is instead just extremely common for it to be present
<pq>
I don't think there is an extremely common one either, outside of what each DE has for their own.
incomoto has joined #wayland
<daniels>
emersion, pq: probably, but then just to prove romangg right I’m still at the beach today
<daniels>
back at work tomorrow
<emersion>
ah, enjoy!
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #wayland
<swick>
I really want the Vulkan extension process to be more open
<swick>
the VK_EXT_present_timing and related stuff is so frustrating
<ishitatsuyuki>
wait, isn't that thing supposed to be *open*?
<ishitatsuyuki>
their usual stuff is even more closed
johnjay has joined #wayland
<LaserEyess>
I was under the impression that VK_EXT_present_timing was still looking for feedback from developers and in particular WSI developers
<swick>
they put out the working draft with a request for comments but it's been more or less a one way street
pi1234 has quit [Ping timeout: 480 seconds]
<LaserEyess>
hm, I guess I took a look at it now and yes it seems like the only responses from teh other side have been updates on the internal decisions made, with 0 information why the decisions were made
<ishitatsuyuki>
sorry to hear that
<swick>
in particular the VK_KHR_present_wait will release soon and I have the suspicion that it might not be the best idea but I just don't know because they're throwing that part over the wall
<ishitatsuyuki>
yeah I also saw that comment, googled it and got confused because zero detail is published rn