ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
leo60228 has quit [Ping timeout: 480 seconds]
leo60228 has joined #dri-devel
yyds has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Ryback_ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Piraty has quit [Remote host closed the connection]
Piraty has joined #dri-devel
Thymo_ has joined #dri-devel
loki_val has quit []
Thymo has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
heat_ has quit [Ping timeout: 480 seconds]
wens has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
dviola has joined #dri-devel
ohmadcs^ has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
tertl8 has joined #dri-devel
Mary has quit [Quit: The Lounge - https://thelounge.chat]
Mary has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
wens has joined #dri-devel
Company has quit [Remote host closed the connection]
vignesh has quit [Quit: Updating details, brb]
vignesh has joined #dri-devel
Company has joined #dri-devel
aravind has joined #dri-devel
rmckeever has quit [Quit: Leaving]
smiles_1111 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
lemonzest has joined #dri-devel
Company has quit [Quit: Leaving]
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
Duke`` has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
benjaminl has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
sima has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
bgs has joined #dri-devel
fab has quit [Quit: fab]
samuelig has quit [Quit: Bye!]
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
yyds has quit []
samuelig has joined #dri-devel
yyds has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
crabbedhaloablut has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
samuelig has quit [Quit: Bye!]
loki_val has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
sgruszka_ has joined #dri-devel
fab has joined #dri-devel
pcercuei has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frankbinns has joined #dri-devel
Haaninjo has joined #dri-devel
mvlad has joined #dri-devel
jkrzyszt_ has joined #dri-devel
<MrCooper> haasn: updates for an invisible surface affecting the refresh rate is probably a kwin issue
<MrCooper> dottedmag: direct scanout isn't required for VRR, fullscreen does make it a lot less difficult though
<zzxyb[m]> may I ask how GLX implements a function similar to eglSwapBufferWithDamage
<zzxyb[m]> for (const QRect &r : damage) {... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/pUQfyuwQuxPZjyHpnUXMTVKE>)
<MrCooper> ugh, another drm-misc-next PR with 1 MB of diffstat which is mostly noise
<MrCooper> sima: and your one-line reply has all of that noise quoted
tursulin has joined #dri-devel
<MrCooper> https://gitlab.freedesktop.org/mesa/mesa/-/jobs/46277351 ouch, clang-format won't let this in unless it's uglier
djbw has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
smiles_1111 has joined #dri-devel
DodoGTA has quit [Ping timeout: 480 seconds]
DodoGTA has joined #dri-devel
<daniels> MrCooper: luckily I'm working on deleting it :P
rasterman has joined #dri-devel
<karolherbst> isn't there a way to annotate code blocks so clang-format ignores those?
<ccr> // clang-format off|on
<karolherbst> MrCooper: ^^
<MrCooper> that was daniels' change, not mine
phasta has joined #dri-devel
tertl8 has quit [Quit: Connection closed for inactivity]
swalker__ has joined #dri-devel
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #dri-devel
yyds has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
swalker__ has quit [Ping timeout: 480 seconds]
xypron has quit [Quit: xypron]
junaid has joined #dri-devel
xypron has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
<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.
oneforall2 has joined #dri-devel
<_jannau__> sven: see above, that's what you were planning to do for DP-altmode on apple. I'll take a look tonight
<sven> nice, I’ll take a look later as well :)
fab has quit [Quit: fab]
<lumag> thanks a lot!
<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
gildekel has quit [Quit: Connection closed for inactivity]
<_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
<lumag> _jannau__, but what should be the correct connector type? It is not a DRM_MODE_CONNECTOR_DisplayPort.
<_jannau__> the usb-c dp-altmode connector on my intel laptop is still a displayport connector
<emersion> i think there are patches on the ML to link DP connectors to USB-C in sysfs?
<emersion> but yeah, these are still DP
<lumag> Why? It is a USB connector, which is multipurposed for USB-only, USB+DP or DP-only
<lumag> pmic_glink_altmode already uses DRM_MODE_CONNECTOR_USB for it.
<emersion> it's just how all other drivers are behaving
<emersion> USB has been introduced recently, for GUD
<_jannau__> it's not entirely clear to me if it should be the physical connector or the electrical signal used
<lumag> drivers/soc/qcom/pmic_glink_altmode.c: alt_port->bridge.type = DRM_MODE_CONNECTOR_USB;
<emersion> that's surprising
rz has joined #dri-devel
<emersion> might be even more surprising if you have a USB connector with a PATH property with "mst:" in it
<_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
<_jannau__> it's not obvious and I started as well with using DRM_MODE_CONNECTOR_USB for usb-c/dp-altmode
rz_ has quit [Remote host closed the connection]
<lumag> Moreover the (deprecated) DP-altmode pin assignments A and B defined USB signalling for the DP lanes.
<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
<lumag> So even on the electrical level it (can) be a USB connector
MrCooper has quit [Quit: Leaving]
<lumag> sven, yeah, we are describing everything in the graph, but then the usb-c-connector (TCPM) registers a final drm_bridge
<sven> ah, I must’ve missed that
<sven> that’s what I get for quickly skimming that patch during my lunch break ;)
<lumag> emersion, _jannau__: BTW, what connector type should be used for MHL, when we have HDMI converted and stuffed into micro-USB?
<emersion> note, there is also a "subconnector" property to describe the underlying physical connector
<emersion> for instance if a DP signal is stuffed into DVI-D, the connector is DP, and subconnector is DVI-D
<emersion> (with a DP → DVI adapter)
<emersion> also happens if an HDMI laptop connector is wired internally to a DP GPU port
<emersion> all of my messages are strictly about uAPI btw, nothing kernel-internal
MrCooper has joined #dri-devel
<lumag> emersion, and drm_dvi_i_dp_subconnector_enum_list doesn't include USB.
<emersion> that one's for DVI
<emersion> hm
<emersion> nevermind
<lumag> sorry, drm_dp_subconnector_enum_list
<emersion> is it for DVI-I *and* DP?
<emersion> ah, right
<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 :)
<emersion> clearly document what connector type is, what subconnector means, especially in weird and complexited scenarios like DP alt mode
<emersion> with adapters and DP-MST
<lumag> Yep. And also drm_connector_attach_dp_subconnector_property() doesn't play well with the drm_bridge_connector
<emersion> complicated*
<emersion> maybe we need a new uAPI, maybe not
<emersion> real_connector_type_this_time_i_swear
<lumag> :-D
<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
<lumag> And what is DRM_MODE_SUBCONNECTOR_Native ?
kts has joined #dri-devel
<lumag> Yes, that is why we were using DRM_MODE_CONNECTOR_USB, less confusion.
<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.
<emersion> DRM_MODE_SUBCONNECTOR_Native is when there is no particular subconnector
<emersion> e.g. DP screen connected to DP port on GPU
<emersion> lumag: to me using the USB connector type is "most confusion" for user-space
<lumag> I was thinking from the user point of view.
<emersion> user != user-space
<emersion> exposing USB connectors clashes with what other drivers are doing
<emersion> e.g. my USB-C port on AMD GPU shows up as DP
fab has joined #dri-devel
<lumag> Yes, same here on intel. It's a pity that this was not noticed when we brought up pmic_glink.
<lumag> ok, let's fix that.
<emersion> IMHO (1) do like everybody else (2) come up with a better solution for everybody
<emersion> that way there are no inconsistencies
<lumag> yep
<emersion> if we are to change type semantics
<emersion> (or add new uAPI to supersede it)
Leopold__ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
mslusarz_ has joined #dri-devel
glisse is now known as Guest7227
glisse has joined #dri-devel
mslusarz has quit [Ping timeout: 480 seconds]
<lumag> emersion, _jannau__: I've sent the v4, chaning type to DisplayPort. Before I rush to implement the subconnector story, do you think if it is fine to stuff that into drm_bridge_connector.c? I don't see another good place for that.
mareko has quit [Ping timeout: 480 seconds]
Guest7227 has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: Lost terminal]
<lumag> So when the drm_bridge_connector is created, it can handle the DP connectors by creating the property and setting it to the predefined value.
<lumag> And another question is about eDP. I see that amdgpu registers the property for eDP connectors, while intel driver skips them. Your suggestion?
mareko has joined #dri-devel
dri-logger has joined #dri-devel
pcercuei has joined #dri-devel
samuelig has joined #dri-devel
<emersion> hm, does amdgpu always set the prop to Native for eDP?
<emersion> it sounds a bit weird to register the prop for eDP, since it's all hidden from the user
<lumag> I think it will be set to Unknown, the default
Leopold has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
<zamundaaa[m]> emersion: I don't see the subconnector property on the eDP connector on my Ryzen laptop
<lumag> Hmm, in amdgpu_connector_add():
<lumag> if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
<lumag> connector_type == DRM_MODE_CONNECTOR_eDP) {
<lumag> drm_connector_attach_dp_subconnector_property(&amdgpu_connector->base);
<lumag> }
<zamundaaa[m]> weird
<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).
<lumag> So, maybe we should fix the AMD instead. Set the connector type to USB and subtype to VGA/DVID/HDMI/DP.
<lumag> (and intel too, but intel doesn't seem to care about the subconnector value).
<lumag> emersion, ^^
lemonzest has quit [Quit: WeeChat 3.6]
<emersion> we can't change the existing type
<emersion> this will break user-space
lemonzest has joined #dri-devel
<emersion> e.g. my users have DP-1 configured in their config file
lemonzest has quit []
lemonzest has joined #dri-devel
lemonzest has quit []
<lumag> True :-(
<lumag> Then we have no good way of specifying that this is DP-in-USB.
lemonzest has joined #dri-devel
cmichael has joined #dri-devel
<emersion> what would make the most sense for consistency with existing drivers is connector=DP, subconnector=USB(C?)
<emersion> and specify that connector reflects the signal protocol, not the physical hw
<emersion> one important difference is that connector type is static, while subconnector is dynamic
<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
<emersion> hubs*
<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.
<lumag> So it should be DP/HDMI, DP/Native, etc. rather than DP/USB
<lumag> My opinion is that this should be USB/None, USB/HDMI, USB/DisplayPort, etc (for new devices).
<lumag> This will divert from existing users, but it might be better from the future point of view.
<emersion> this changes the meaning of the connector type
<emersion> so i'm not a fan
<emersion> ie. in some drivers it means something, in other drivers something else
<lumag> It seems, there is no perfect solution :-(
<lumag> Because otherwise I'll change the meaning of subconnector type.
<lumag> ugly :-(
ernstp_____ has left #dri-devel [#dri-devel]
kts has quit [Ping timeout: 480 seconds]
<emersion> lumag: hm, i don't see the problem you're worried about…
<emersion> is there an issue if you driver sets connector type = DP and subconnector = USBC?
<lumag> This will differ from AMD, who defines it to the type of the connected dongle.
<lumag> If I'm not mistaken.
<emersion> and you can't use the dongle type?
<emersion> USBC for no dongle, and HDMI/DVI/whatever if there is a dongle?
<lumag> Which would mean that subtype changes on dongle plug?
ernstp has joined #dri-devel
<emersion> yeah, subconnector behaves this way
<emersion> the subconnector changes when a screen is connected
mareko_ has joined #dri-devel
dri-logg1r has joined #dri-devel
mareko has quit [Ping timeout: 480 seconds]
mslusarz_ has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
MajorBiscuit has joined #dri-devel
<lumag> emersion, ack, thanks for the explanation then.
mslusarz has joined #dri-devel
glisse has joined #dri-devel
hikiko has joined #dri-devel
hikiko has quit []
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
yyds has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
digetx has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
<emersion> what's next?
<emersion> let me know if i can help
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
pepp has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
<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 :(
yyds has quit [Remote host closed the connection]
<daniels> emersion: is there anything on your list I could look at whilst I'm in the area tho?
sgruszka_ has quit [Ping timeout: 480 seconds]
kasper93_ has joined #dri-devel
kasper93 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
ced117 has joined #dri-devel
Major_Biscuit has quit []
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
kts has joined #dri-devel
benjaminl has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<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
<karolherbst> or at least the fedora bits of it
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
kzd has joined #dri-devel
glennk has quit [Read error: Connection reset by peer]
cmichael has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
glennk has joined #dri-devel
tobiasjakobi has quit []
tursulin has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
djbw has joined #dri-devel
tobiasjakobi has quit []
MrCooper has quit [Quit: Leaving]
frankbinns has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
kasper93_ is now known as kasper93
kts has quit [Quit: Leaving]
smiles_1111 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Quit: Ping timeout (120 seconds)]
ybogdano has joined #dri-devel
junaid has joined #dri-devel
iive has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has joined #dri-devel
kzd has quit [Quit: kzd]
mvlad has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
junaid has quit [Remote host closed the connection]
maxv has joined #dri-devel
<maxv> does gbm_bo_create* always create a zeroed buffer?
<emersion> no
<maxv> Is this hardware dependent? I haven't yet seen a gbm_bo which wasn't initially cleared
<emersion> yeah, it is
<emersion> in my experience, Intel clears, while AMD doesn;t
<maxv> Interesting, I use AMD
bgs has quit [Remote host closed the connection]
maxv has quit [Remote host closed the connection]
cambrian_invader has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
mareko_ is now known as mareko
rgallaispou1 has joined #dri-devel
phasta has quit [Remote host closed the connection]
rgallaispou has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
Duke`` has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
eukara has quit []
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
heat_ has quit [Remote host closed the connection]
kzd has joined #dri-devel
iive has quit [Quit: They came for me...]
JohnnyonFlame has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel