07:30 MrCooper: haasn: updates for an invisible surface affecting the refresh rate is probably a kwin issue
07:31 MrCooper: dottedmag: direct scanout isn't required for VRR, fullscreen does make it a lot less difficult though
07:35 zzxyb[m]: may I ask how GLX implements a function similar to eglSwapBufferWithDamage
07:35 zzxyb[m]: for (const QRect &r : damage) {... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/pUQfyuwQuxPZjyHpnUXMTVKE>)
07:42 MrCooper: ugh, another drm-misc-next PR with 1 MB of diffstat which is mostly noise
07:43 MrCooper: sima: and your one-line reply has all of that noise quoted
07:54 MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/46277351 ouch, clang-format won't let this in unless it's uglier
08:26 daniels: MrCooper: luckily I'm working on deleting it :P
08:34 karolherbst: isn't there a way to annotate code blocks so clang-format ignores those?
08:37 ccr: // clang-format off|on
08:37 karolherbst: MrCooper: ^^
08:37 ccr: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code
08:37 MrCooper: that was daniels' change, not mine
09:43 lumag: airlied, mripard, jani, I'm trying to push out the remaining pieces of DP-altmode support for msm platforms. Who should be the reviewer for https://patchwork.freedesktop.org/series/120393 ? It seems the series was mostly ignored by all the parties.
09:53 _jannau__: sven: see above, that's what you were planning to do for DP-altmode on apple. I'll take a look tonight
09:57 sven: nice, I’ll take a look later as well :)
10:09 lumag: thanks a lot!
10:10 lumag: _jannau__, sven, the second part that might be interesting to you is https://lore.kernel.org/linux-arm-msm/20230728100857.471984-2-dmitry.baryshkov@linaro.org/T/#u
10:21 _jannau__: lumag: I'm not sure if DRM_MODE_CONNECTOR_USB is a good choice for usb-c dp-altmode. it was added for the gadget usb device
10:21 lumag: _jannau__, but what should be the correct connector type? It is not a DRM_MODE_CONNECTOR_DisplayPort.
10:21 _jannau__: the usb-c dp-altmode connector on my intel laptop is still a displayport connector
10:22 emersion: i think there are patches on the ML to link DP connectors to USB-C in sysfs?
10:23 emersion: but yeah, these are still DP
10:23 lumag: Why? It is a USB connector, which is multipurposed for USB-only, USB+DP or DP-only
10:23 lumag: pmic_glink_altmode already uses DRM_MODE_CONNECTOR_USB for it.
10:23 emersion: it's just how all other drivers are behaving
10:24 emersion: USB has been introduced recently, for GUD
10:24 _jannau__: it's not entirely clear to me if it should be the physical connector or the electrical signal used
10:24 lumag: drivers/soc/qcom/pmic_glink_altmode.c: alt_port->bridge.type = DRM_MODE_CONNECTOR_USB;
10:25 emersion: that's surprising
10:25 emersion: might be even more surprising if you have a USB connector with a PATH property with "mst:" in it
10:26 _jannau__: even if it is he physical connector, just USB is still bad as you can't use dp-altmode over usb3 type a connectors
10:27 _jannau__: it's not obvious and I started as well with using DRM_MODE_CONNECTOR_USB for usb-c/dp-altmode
10:27 lumag: Moreover the (deprecated) DP-altmode pin assignments A and B defined USB signalling for the DP lanes.
10:28 sven: regarding that second part: we’ll unfortunately have to properly describe the signal path using of_graph because apple allows quite some flexible routing between sources and ports
10:28 lumag: So even on the electrical level it (can) be a USB connector
10:28 lumag: sven, yeah, we are describing everything in the graph, but then the usb-c-connector (TCPM) registers a final drm_bridge
10:29 sven: ah, I must’ve missed that
10:29 sven: that’s what I get for quickly skimming that patch during my lunch break ;)
10:35 lumag: sven, I have pushed my branch to https://git.codelinaro.org/dmitry.baryshkov/linux/-/commits/test-rb5-dp,
10:37 lumag: emersion, _jannau__: BTW, what connector type should be used for MHL, when we have HDMI converted and stuffed into micro-USB?
10:38 emersion: note, there is also a "subconnector" property to describe the underlying physical connector
10:39 emersion: for instance if a DP signal is stuffed into DVI-D, the connector is DP, and subconnector is DVI-D
10:39 emersion: (with a DP → DVI adapter)
10:40 emersion: also happens if an HDMI laptop connector is wired internally to a DP GPU port
10:41 emersion: all of my messages are strictly about uAPI btw, nothing kernel-internal
10:42 lumag: emersion, and drm_dvi_i_dp_subconnector_enum_list doesn't include USB.
10:43 emersion: that one's for DVI
10:43 emersion: hm
10:43 emersion: nevermind
10:43 lumag: sorry, drm_dp_subconnector_enum_list
10:43 emersion: is it for DVI-I *and* DP?
10:43 emersion: ah, right
10:44 emersion: i do agree that the current situation is not great, but instead of blindly adding new entries it would be nice to come up with a well-defined scheme :)
10:45 emersion: clearly document what connector type is, what subconnector means, especially in weird and complexited scenarios like DP alt mode
10:45 emersion: with adapters and DP-MST
10:45 lumag: Yep. And also drm_connector_attach_dp_subconnector_property() doesn't play well with the drm_bridge_connector
10:45 emersion: complicated*
10:45 emersion: maybe we need a new uAPI, maybe not
10:46 emersion: real_connector_type_this_time_i_swear
10:46 lumag: :-D
10:47 emersion: subconnector was introduced to fix the issue of users getting confused when they get a DP connector but look at their hw and there is no DP port there
10:48 lumag: And what is DRM_MODE_SUBCONNECTOR_Native ?
10:50 lumag: Yes, that is why we were using DRM_MODE_CONNECTOR_USB, less confusion.
10:52 lumag: emersion, I can propose to take a look at extending the drm_dp_subconnector_enum_list, updating drm_bridge_connector and then fixing the remaining drivers. But from the 'least confusion' I'd suggest keeping _USB for now. I can send v4 adding a FIXME there.
10:52 emersion: DRM_MODE_SUBCONNECTOR_Native is when there is no particular subconnector
10:52 emersion: e.g. DP screen connected to DP port on GPU
10:53 emersion: lumag: to me using the USB connector type is "most confusion" for user-space
10:53 lumag: I was thinking from the user point of view.
10:53 emersion: user != user-space
10:54 emersion: exposing USB connectors clashes with what other drivers are doing
10:54 emersion: e.g. my USB-C port on AMD GPU shows up as DP
10:55 lumag: Yes, same here on intel. It's a pity that this was not noticed when we brought up pmic_glink.
10:56 lumag: ok, let's fix that.
10:57 emersion: IMHO (1) do like everybody else (2) come up with a better solution for everybody
10:57 emersion: that way there are no inconsistencies
10:59 lumag: yep
11:02 emersion: also kind-of-related is https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html
11:02 emersion: if we are to change type semantics
11:03 emersion: (or add new uAPI to supersede it)
11:22 emersion: hm, does amdgpu always set the prop to Native for eDP?
11:23 emersion: it sounds a bit weird to register the prop for eDP, since it's all hidden from the user
11:25 lumag: I think it will be set to Unknown, the default
11:27 zamundaaa[m]: emersion: I don't see the subconnector property on the eDP connector on my Ryzen laptop
11:29 lumag: Hmm, in amdgpu_connector_add():
11:29 lumag: if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
11:29 lumag: connector_type == DRM_MODE_CONNECTOR_eDP) {
11:29 lumag: drm_connector_attach_dp_subconnector_property(&amdgpu_connector->base);
11:29 lumag: }
11:32 zamundaaa[m]: weird
11:32 lumag: After glancing at the amd code, I'm not sure what value should I set. The AMD code gets the attached type from the dongle and sets the subcnnector to the type of the dongle (e.g. HDMI, DVI, etc).
11:33 lumag: So, maybe we should fix the AMD instead. Set the connector type to USB and subtype to VGA/DVID/HDMI/DP.
11:33 lumag: (and intel too, but intel doesn't seem to care about the subconnector value).
11:34 lumag: emersion, ^^
11:35 emersion: we can't change the existing type
11:35 emersion: this will break user-space
11:36 emersion: e.g. my users have DP-1 configured in their config file
11:39 lumag: True :-(
11:41 lumag: Then we have no good way of specifying that this is DP-in-USB.
11:44 emersion: what would make the most sense for consistency with existing drivers is connector=DP, subconnector=USB(C?)
11:44 emersion: and specify that connector reflects the signal protocol, not the physical hw
11:45 emersion: one important difference is that connector type is static, while subconnector is dynamic
11:46 emersion: my AMD GPU USB-C connectors will always show up as DP (connector type), but depending on adapters and hibs plugged in, subconnector can change
11:46 emersion: hubs*
11:47 lumag: Yeah, that's the problem. If we want to behave in the same way as AMD, we should set subconnector to the type of the dongle.
11:49 lumag: So it should be DP/HDMI, DP/Native, etc. rather than DP/USB
11:50 lumag: My opinion is that this should be USB/None, USB/HDMI, USB/DisplayPort, etc (for new devices).
11:52 lumag: This will divert from existing users, but it might be better from the future point of view.
11:54 emersion: this changes the meaning of the connector type
11:54 emersion: so i'm not a fan
11:55 emersion: ie. in some drivers it means something, in other drivers something else
11:55 lumag: It seems, there is no perfect solution :-(
11:56 lumag: Because otherwise I'll change the meaning of subconnector type.
11:57 lumag: ugly :-(
11:58 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24285
12:13 lumag: emersion, ack, thanks for the explanation then.
14:18 emersion: daniels, ah, nice cleanup in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24347
14:18 emersion: what's next?
14:18 emersion: let me know if i can help
14:34 daniels: emersion: I'll duck back into Wayland & GBM to delete some of the open-coded format tables as well as clean up the config handling a little bit, but sadly probably going to just stop there; it's all work for Panfrost rather than Wayland/GBM in and of themselves :(
14:41 daniels: emersion: is there anything on your list I could look at whilst I'm in the area tho?
16:07 karolherbst: MrCooper: I mess around with the fedora container a little as I need meson-1.2, mind reviewing the patch? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21451/diffs?commit_id=e93c85a0b2e17ee7d583e7a8c6de859472c1f734
16:08 karolherbst: or at least the fedora bits of it
18:51 maxv: does gbm_bo_create* always create a zeroed buffer?
19:01 emersion: no
19:08 maxv: Is this hardware dependent? I haven't yet seen a gbm_bo which wasn't initially cleared
19:08 emersion: yeah, it is
19:08 emersion: in my experience, Intel clears, while AMD doesn;t
19:08 maxv: Interesting, I use AMD