02:27 <gryffus_> drm_info|grep Mode gives me "Mode: 1920x1080@60.00 phsync nvsync"

02:28 <gryffus_> But I doubt think the adapter supports only 1 resolution

02:28 <danieldg> gryffus_: grep for hsync instead to get a list, or search it

02:29 <danieldg> they aren't prefixed with Mode

02:29 <gryffus_> danieldg: yeah, only 1920x1080

02:29 <gryffus_> "1920x1080@60.00 preferred driver phsync nvsync" and "1920x1080@48.00 driver phsync nvsync"

02:29 <danieldg> look in the Connector section

02:30 <gryffus_> https://susepaste.org/62c936730b59

02:30 <danieldg> This service is now obsolete

02:30 <gryffus_> https://paste.opensuse.org/62c936730b59

02:30 <gryffus_> sorry wrong link :x

02:31 <danieldg> ah, eDP might actually only support one resolution

02:32 <gryffus_> I am using even 640 x 480 on both X11 and Windows

03:30 <bwidawsk> gryffus_: so there's no reason why you can't render the surfaces at lower resolutions, but either the compositor, or the display is going to scale it to 19x10

03:30 <bwidawsk> I know nothing about how KDE handles this stuff, but fractional scaling should allow this

06:31 <cmeissl[m]> Is it required to send frame events for wl_touch.up? Seems that some compositor send it and some not.

06:31 <cmeissl[m]> I would expect wl_touch.cancel and wl_touch.up to take immediate effect and not require a separate frame event.

07:14 <kennylevinsen> cmeissl[m]: It does not seem specified well enough, and I do not see an immediate reason why down *wouldn't* use the frame event

07:14 <kennylevinsen> ah, up

07:16 <kennylevinsen> Not sure tbh - up and cancel say "no further events will be sent for this touch point", but whether that implies that no frame event is sent is unclear

07:17 <kennylevinsen> up for a clarifying patch? :)

07:26 <cmeissl[m]> kennylevinsen: thx. yeah, I will open an issue. seems that this has been changed in weston: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/980

07:28 <daniels> 'no further events will be sent for this touch point' was written before 'frame' was introduced

07:29 <daniels> cancel explicitly states 'No frame event is required after the cancel event', but up doesn't

07:29 <daniels> so I'd say that cancel+frame is unexpected but harmless, whereas up+frame is mandatory

07:32 <cmeissl[m]> interesting , thx daniels this seems to match the implementation in wlroot which internally tracks needs_touch_frame and sets it for up, but not for cancel. afaict weston would send frame in both cases.

07:33 <cmeissl[m]> will re-test, but iirc gnome did not send frame after up

07:35 <kennylevinsen> Ah yes, ifreund updated the cancel event a month ago to specify that no frame event is needed

07:40 <cmeissl[m]> Ah, been looking at wayland.app which seems to not have been updated

07:40 <cmeissl[m]> it is indeed in the xml

07:41 <kennylevinsen> same :)

07:43 <cmeissl[m]> k, will update the implementation in smithay to allow sending frame events for up. thanks :)

09:35 <MrCooper> WhyNotHugo: did you read https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/363#note_2404600 ?

16:01 <LimeOn> Hello. I am trying to use a specific keyboard layout variant (russian, phonetic) but i am unable to set it under wayland. Everything seems to work in X11 with the same command. In wayland the three layouts work, the toggle key also works but the russian variant is not applied. This is the command i am using: 'localectl --no-convert set-x11-keymap latam,ru,gr pc105 deadtilde,phonetic, grp:lwin_toggle' im using archlinux under labwc

16:02 <LimeOn> the russian layout provided is not the 'phonetic' one, and the latma variant also present a small difference(so maybe the variant is also not applied)

16:02 <LimeOn> latam*

16:03 <LimeOn> Any hints on how could i do this in wayland? i have been searching and trying other layouts without luck

16:04 <Consolatis> LimeOn: this channel is for discussion about the wayland protocols, suggest either asking in the compositor channel or starting a discussion / issue in the compositor repo instead

16:05 <LimeOn> oh hello Consolatis, sorry for the mess, i forgot to read the topic(coming from libera room)

16:05 <Consolatis> #labwc at libera then

17:18 <wlb> weston Merge request !1513 opened by Derek Foreman (derekf) renderer: Move dmabuf setup into renderer init https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1513 [Core compositor], [GL renderer]

18:56 <wlb> wayland Merge request !391 opened by Hugo (WhyNotHugo) Clarify divergence in compositor behaviour https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/391

19:09 <vyivel> should've been a protocol error lol

19:11 <gryffus_> bwidawsk: but why should I use scaling if the adapter is able outputting desired resolution natively without any scaling overhead

19:11 <bwidawsk> gryffus_: the mode you requested wasn't available

19:12 <bwidawsk> embedded panels often only have 1 mode

19:13 <gryffus_> How X11 does it then? https://imagebin.ca/v/81D2HnkVgPet

19:14 <Company> vyivel: wayland should have a conformance testsuite

19:14 <gryffus_> Some ugly hack?

19:15 <daniels> Company: yep

19:15 <vyivel> isn't there at least one and a half already

19:16 <gryffus_> bwidawsk: I mean, is it EDID problem? Or where exactly wayland gets the "only one mode available" info from?

19:19 <bwidawsk> gryffus_: yeah, bit off-topic. driver parses edid and exposes it to the compositor

19:19 <zamundaaa[m]> gryffus_: Xorg does support it through an ugly hack, and KWin does the same ugly hack for now

19:20 <zamundaaa[m]> I just kept the "common mode" list a bit more minimal, to not unnecessarily bloat the resolution list in the display settings

19:21 <gryffus_> I am confused, isn't this the decoded EDID? https://imagebin.ca/v/81D4X3CcTyNo

19:23 <gryffus_> zamundaaa[m]: ah, :( is there anything I can do to get my modes back? Please do not take "power" from "power users" :(

19:24 <wlb> weston Issue #905 opened by Julian Orth (mahkoh) Segfault when attached buffer is destroyed https://gitlab.freedesktop.org/wayland/weston/-/issues/905

19:29 <zamundaaa[m]> gryffus_: for now, you can patch KWin to add the mode you want to the list: https://invent.kde.org/plasma/kwin/-/blob/master/src/backends/drm/drm_connector.cpp?ref_type=heads#L363

19:29 <gryffus_> amazing thanks!

19:29 <zamundaaa[m]> User configurable custom modes are on the roadmap too, then the list can be removed and you can just specify whatever weird resolution you want

19:29 <gryffus_> cool news! :)