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
<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
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>
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.
<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?