12:35 jani: couple of fairly straightforward patches needing review, https://lore.kernel.org/r/902c8e09d25b99391fd9c92d95af07c01d7b7cbd.1715353572.git.jani.nikula@intel.com and https://lore.kernel.org/r/b6aa1ea30ae85ef9e9814315d3437e82f0ba6754.1715353572.git.jani.nikula@intel.com, anyone?
13:37 feaneron: hi. i recently started looking at replacing GLX by EGL/X11 in Mutter (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3760), but one blocker showed up. it seems like there is no EGL version of GLX_INTEL_swap_event. does anybody know if there are alternatives to that?
15:03 warpme: guys: i need some brainstorming: i'm developing multimedia appliance. At boot it uses fb to draw boot splash screen. On x86_64 (n3450) boot splash screen was working ok some kernel revisions ago - but since some last kernel revisions boot splash screen just stopped refreshing. It shows first, initial "state" but then is not refreshed. Asking here as: 1)when system finally boots, boot splash daemon seems work ok (i tested by asking
15:03 warpme: splash screen daemon to show examplary progress. It works. 2)poweroff/reboot splash screen also works; 3)exactly the same distro recompiled for aarch64 have splash working; x86_64 with nvidia gfx also works ok. It looks like only intel i915 has issue. What will be your suggestion here?
16:47 dviola: I would like to submit some typo fixes to some projects but looks like I'm not allowed to fork on: https://gitlab.freedesktop.org/
16:56 Sachiel: dviola: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new?issuable_template=User%20verification
17:07 dviola: Sachiel: oh
17:07 dviola: thanks
17:51 dviola: is fork access given on a per-project basis?
17:53 Sachiel: I think per-user, you can ask more about that on #freedesktop
17:59 dviola: oh, ok, thanks
18:02 alanc: dviola: See https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home
21:03 lumag: dianders, what is the current expectation regarding panel-specific data in panel-edp and panel-specific compat entries?
21:04 lumag: dianders, e.g. do we really need an entry for boe,nv133wum-n63 there?
21:04 dianders: lumag: I'd expect that for most panels you just use the generic "edp-panel" and then put entry mapping panel ID to timing in the source code.
21:05 lumag: dianders, ack. Should we possibly add a comment there?
21:05 dianders: In general the specific compatible strings in panel-edp.c are all for backward compatibility...
21:05 lumag: (and maybe review / clean up existing data)
21:05 dianders: Comment sounds fine. Where is there?
21:06 dianders: Before removing support for things like "boe,nv133wum-n63", we'd want to decide how much folks care about dts backward compatibility. :-/
21:08 lumag: dianders, I'd guess, if the compat is mentioned in DTS and/or bindings, then it must remain.
21:08 lumag: (or in the old sc7180 board files)
21:09 lumag: dianders, Let's get comment first and review the list of the compats afterwards.
21:09 dianders: Right. There are a bunch of old Chromebooks w/ various other SoCs that also still use the old method of specifying a panel, too.
21:10 dianders: lumag: I'm pretty sure I had a comment _somewhere_, but have to find it. The trick is finding the right place to put a comment like that where someone would read it. Where were you suggesting?
21:10 lumag: next to edp-panel compat
21:11 dianders: In the source code, or the yaml, or both?
21:14 lumag: Maybe both
21:15 dianders: Presumably we could also split the yaml file for all of the eDP panels since I never bothered moving them out of `panel-simple.yaml`. Those could all move to `panel-edp-lagacy.yaml` and maybe that would make it obvious enough?
21:18 dianders: lumag: FWIW, for the panels that are in panel-edp I tried to document where they were used in the commit that moved them. For instance, see commit 3fd68b7b13c2 ("drm/panel-edp: Move some wayward panels to the eDP driver").
21:18 lumag: dianders, ack
21:18 dianders: Do you want to post a patch and I can review it, or you want me to post something?
21:18 lumag: as for panel-edp-legacy.yaml it sounds good to me.
21:19 lumag: As you have all the context and the history, it might be better if you post it.
21:19 dianders: lumag: Sure. It shouldn't take too long I think.
21:19 lumag: (at some point, definitely not a top-priority thing)
21:19 dianders: lumag: If I don't do it now I'll never do it
21:20 lumag: dianders, :-D
22:39 dianders: lumag: OK <https://lore.kernel.org/r/20240520153813.1.Iefaa5b93ca2faada269af77deecdd139261da7ec@changeid>. I didn't put any comments in the source code since I figure anyone trying to add a new panel compatible will look for the file where all the other compatibles are and see that it's called legacy and read the desc.
22:57 lumag: dianders, I fear that enough people just add compats to the source file rather than touching the bindings
22:58 dianders: lumag: You think that would get through code review these days?
22:58 lumag: dianders, yes :-(
22:58 dianders: lumag: that sucks. I would certainly NAK it and get_maintainer says they're supposed to CC me...
22:58 lumag: Also it is easier to reduce the burden on drm/dDT maintainers
22:59 dianders: lumag: OK, how about you add the comment to the source code and post that patch. I don't think there's any need for it to be in the same series as mine.
22:59 lumag: dianders, ack