10:17 <wlb> weston Issue #566 opened by () Demote weston-terminal to a demo https://gitlab.freedesktop.org/wayland/weston/-/issues/566 [Clients]

12:15 <pq> emersion, thanks for mentioning foot, looks like just the thing instead of weston-terminal. :-)

12:23 <jadahl> tbh, foot was pretty neat. except the name. leaves a bad taste :P

12:25 <emersion> ahah

12:28 <vsyrjala> i thought it was some kind of tmnt reference. apparently not

12:45 <ifreund> just gotta read it as foo T short for foo term instead of foot :D

12:48 <jadahl> the immediate image that came to my mind was the end result of a day hiking for a day

12:48 <jadahl> *of a days hike

12:50 <ifreund> sounds like you need better hiking shoes :P

12:51 <pq> the gnome logo would fit though, right? :-)

12:51 <jadahl> pq: luckly I don't see that logo that often

12:52 <jadahl> or maybe words have bigger impact than logos on me :P

12:52 <pq> I just realized it has only 4 toes.

12:52 <jadahl> maybe gnomes only have 4 toes

13:01 <zubzub> make sure you use the latest version of foot, version 1.6 has a nasty resizing bug

13:21 <pq> zubzub, looks like debian stable has 1.6.4, is that good or broken?

13:22 <pq> or maybe debian pulled a patch, since it's 1.6.4-1

13:34 <dnkl> pq: debian's foot is old, and unpatched, afaik

13:36 <dnkl> I believe there's an MPR(?) package that's more up to date (not a Debian user myself)

13:38 <pq> I can always build it myself, didn't seem too much of dependencies. :-)

14:25 <MrCooper> pq: the part after the dash in Debian package versions is the Debian specific revision, so 1.6.4-1 is the first Debian package revision for upstream version 1.6.4

14:26 <MrCooper> (all non-native Debian packages have a dash and revision in their version)

14:32 <pq> What's a native Debian package then?

14:33 <SardemFF7> projects maintained by Debian (as both upstream and downstream)?

14:36 <MrCooper> yep

15:11 <daniels> I think dmabuf-feedback is good to go :o

15:11 <pq> \o/ !!!

15:12 <daniels> really super pleasing flipping on the shade-composited-surfaces mode, making something fullscreen and watching it flip over to green after a second or so

15:12 <pq> I am too. Till next week! \o.

15:12 <daniels> hehe

15:12 <daniels> o/

15:12 <pq> wait, *to* green?

15:15 <MrCooper> green means good right? :P

15:22 <daniels> pq: … from

16:27 <wlb> weston Merge request !731 opened by () Cache gbm_bo and drm_fb for client buffers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/731 [DRM/KMS backend]

18:02 <zubzub> 14:21 < pq> zubzub, looks like debian stable has 1.6.4, is that good or broken?

18:02 <zubzub> broken

18:45 <caveman> zubzub: are you arab?

18:53 <pounce> OK n00b question why does the wayland protocol use integral scaling from (what I assume to be) 96 DPI instead of providing DPI directly like MacOS

19:00 <daniels> pounce: https://lists.fedoraproject.org/pipermail/devel/2011-October/157760.html

19:01 <pounce> oh spicy thread thanks

19:01 <daniels> basically: scaling is useful to people, DPI is very rarely useful

19:01 <daniels> integral rather than fractional is quite coarse yes, but there are ways to get around that which people are discussing as protocol enhancements

19:02 <daniels> (put simply, you may very well want your clients to know that the desired scaling factor is 1.8, but you do _not_ want to be dealing with 1.8x in the protocol itself, because then you have fractional pixels and the only thing more difficult than handling that correctly is figuring out how you should even handle it)

19:03 <pounce> why does the scaling factor change the pixel geometry?

19:05 <daniels> if it didn't, there'd be no need for scaling ;)

19:05 <daniels> there are a couple of relevant co-ordinate spaces - there is buffer co-ordinate space, surface co-ordinate space, and then other compositor-internal ones; all of them involve scaling in order to transparently handle non-scaling-aware clients

19:06 <daniels> (as well as things like rotation, cropping, etc)

19:06 <pounce> sure

19:07 <pounce> i was going to complain and say in my experience this doesn't fix anything, since screencap-ing is still broken, but that's just because pipewire streams don't contain the scaling information that exists everywhere else in wayland

19:21 <zubzub> 19:45 < caveman> zubzub: are you arab?

19:21 <zubzub> no I'm dad

19:57 <zubzub> jadahl: do you have any tips perhaps on how to deal with the shm pointer usage in gstream cfr https://gitlab.gnome.org/GNOME/gtk/-/issues/4460#

21:04 <zubzub> what are the semantics of an shm_pool/buffer when the client resizes and the compositor has a reference? Does something like a copy on write exist so ie the compositor can still see & use the old state until the pool has been released?

21:30 <jadahl> zubzub: some how I have vague memories of it being discussed years ago, but can't remember much other than it being rticky

21:52 <zubzub> if its legal to change the shm_pool while an shm buffer is not released, contradict the wayland requirement that a client should not change buffers it has committed?

22:00 <zubzub> because if it's ok to do so, the shm spec has an spec hole imho, or if not, gtk4 has a bug(?)

22:02 <jadahl> zubzub: found the mail thread I was thinking of: https://lists.freedesktop.org/archives/wayland-devel/2016-February/026905.html

22:58 <daniels> ManMower: ^

23:17 <daniels> emersion: what do you want to do with dmabuf-feedback btw? I'm good with the Weston + Mesa + sample-client implementations; they feel good to use, definitely work on multiple platforms, so absent bugs I think we're good to go, just need our third real implementation from wlr