ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
a-865 has quit [Quit: ChatZilla 0.17 [SeaMonkey 2.53.17/20230727221859]]
frankbinns1 has joined #dri-devel
<karolherbst> seems to work :)
<gfxstrand> First try, even?
<karolherbst> yeah
<gfxstrand> \o/
<karolherbst> didn't theck the shader though
<gfxstrand> Let's throw it at some CI to see if it blows rusticl up
<karolherbst> I have a collection of other random patches I'll have to upstream anyway and tomorrow is time off, so I might do some of that stuff next week
<karolherbst> I also need SpvCapabilityFPFastMathModeINTEL for random stuff, but I think we can just enable that one...
frankbinns has quit [Ping timeout: 480 seconds]
<karolherbst> getting a lot of "iris: Failed to submit batchbuffer: No space left on device" in random tests... sadly nothing tells me what the problem is, though I think my SVM impl is borked
<alyssa> gfxstrand: have you considered using nir_shader_intrinsics_pass
<alyssa> :~P
<karolherbst> there is a memcpy3D tests :')
<karolherbst> memcpy3D: ../src/compiler/nir/nir.h:1655: nir_deref_mode_is_in_set: Assertion `nir_deref_mode_must_be(deref, modes)' failed. ah yes... that issue
<karolherbst> that's even _with_ the MR fixing some of it
<karolherbst> but there is more annoying stuff going on
<karolherbst> generic pointer nonsense
<karolherbst> CapabilityInt64Atomics oh boi...
zzoon_vacations_till_6th_Aug[m is now known as zzoon
<karolherbst> anyway.. I think I'm happy enough with my current global program varaible implementation, I just have no idea how to deal with those "constant" pointers to variables nonsense :'(
<karolherbst> or rather, I have ideas, I just hate them all
camus has joined #dri-devel
camus2 has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<karolherbst> gfxstrand: I found a couple of tests where I ran into explicit stride asserts after memcpy lowering
<karolherbst> will investigate later
<karolherbst> probably just me having a weird order of passes
<karolherbst> ehh..
<karolherbst> it's after opt_memcpy
<karolherbst> nvm
camus has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
pa has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
<gfxstrand> karolherbst: Pushed with some improvements.
<gfxstrand> Pushed again. One of the fixups was bogus
<gfxstrand> karolherbst: It should now be patching alignments through properly
tlwoerner has joined #dri-devel
yuq825 has joined #dri-devel
<DemiMarie> Are there plans to fix the blocking in vkQueuePresentKHR?
a-865 has joined #dri-devel
<gfxstrand> What do you mean?
<DemiMarie> https://dudemanguy.github.io/blog/posts/2022-06-10-wayland-xorg/wayland-xorg.html complains that vkQueuePresentKHR() blocks if the Wayland compositor is throttling drawing, in violation of the Vulkan spec. Is this accurate, and if so, are there plans to fix it?
<gfxstrand> Uh... I don't think we're violating anything
<gfxstrand> And I don't think we block.
<gfxstrand> Yeah, we have a throttle thing.
<gfxstrand> We have a throttle thing for X11, too.
<gfxstrand> We have them because apps are dumb
<gfxstrand> There's not much I can do with an unhinged rant. If someone wants to file a bug with an example of said misbehavior and can explain what they think Vulkan requires there, we can talk about it. A giant rantpost about how everything is terrible that just assumes the reader agrees isn't actionable.
<DemiMarie> https://github.com/glfw/glfw/issues/1350 or has something changed since then?
<ids1024[m]> If it waits on wl_surface_frame callbacks, it may block indefinitely for occluded windows.
<DemiMarie> gfxstrand: yeah, good point, that is my fault for linking the blog post.
<DemiMarie> sorry about that
<gfxstrand> If the app requests FIFO, yes, we're going to block on frame callbacks. That's literally what they asked us to do.
<DemiMarie> ah okay
<gfxstrand> If you don't want us blocking on frame callbacks, requrest MAILBOX.
<gfxstrand> *request
<DemiMarie> so this is just buggy apps that don’t realize that they need to have an event driven main loop?
<gfxstrand> Or that use FIFO instead of MAILBOX
<gfxstrand> With Wayland, you really should be using MAILBOX and handling the frame callback yourself or in the toolkit.
<DemiMarie> Makes sense
<gfxstrand> And, yes, there's a bit of a mismatch between the way FIFO and SwapInterval are specified and Wayland app throttling.
<DemiMarie> Is using MAILBOX the appropriate thing on other platforms too?
<gfxstrand> Well, you want some amount of throttling everywhere.
<gfxstrand> If you use FIFO, you get throttling.
<gfxstrand> That's what it's for.
<gfxstrand> With Wayland, you can actaully manage it yourself and get something more predictable.
<DemiMarie> makes sense!
<gfxstrand> With X11, the best you can do really is FIFO/eglSwapInterval(1)
<gfxstrand> If you set MAILBOX, there is a 1:1 mapping between vkQueuePresent() and wl_surface.attach/commit.
<gfxstrand> The Vulkan spec even says so. :-)
<DemiMarie> sorry for wasting your time
<gfxstrand> No worries.
<gfxstrand> Oh, I think I know why we do extra blocking in Vulkan for Wayland
<gfxstrand> I guess we do block for everything other than MAILBOX
<gfxstrand> But, also, you should always use MAILBOX with Wayland.
<gfxstrand> Well, we don't block much
<gfxstrand> That's probably more of a documentaiton problem than anything
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
melonai3 has quit [Ping timeout: 480 seconds]
g0b has quit [Ping timeout: 480 seconds]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
g0b has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
g0b has quit [Remote host closed the connection]
bmodem has joined #dri-devel
crabbedhaloablut has joined #dri-devel
melonai3 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
g0b has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
sima has joined #dri-devel
mattst88 has quit [Remote host closed the connection]
mattst88 has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
bgs has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
kem has joined #dri-devel
junaid has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
macromorgan has joined #dri-devel
alanc has quit [Remote host closed the connection]
macromorgan_ has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest9251
macromorgan has joined #dri-devel
Guest9251 has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
aravind has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
vliaskov has joined #dri-devel
aravind has quit [Remote host closed the connection]
ishitatsuyuki has joined #dri-devel
pcercuei has joined #dri-devel
dviola has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
junaid has quit [Quit: leaving]
lynxeye has joined #dri-devel
Haaninjo has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
donaldrobson has joined #dri-devel
aravind has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<MrCooper> gfxstrand: it would be possible in principle to do FIFO without blocking in vkQueuePresentKHR, it would require new Wayland protocol though
<emersion> explicit-sync-v1 can do it
<emersion> er, v2
swalker_ has joined #dri-devel
swalker_ is now known as Guest9265
Guest9265 has quit [Ping timeout: 480 seconds]
<MrCooper> that can't do FIFO semantics
<emersion> i believe it can
<emersion> send an unmaterialized sync point to the compositor, signal the sync point on presentation-time feedback of the previous frame
<MrCooper> or on the frame event, I see, clever :)
junaid has joined #dri-devel
<karolherbst> gfxstrand: new code seems to cause a "Floating point exception (core dumped)"
<karolherbst> but that's probably my fault :)
<karolherbst> no allignment information is there
<karolherbst> I'll post more infos on the MR
junaid has quit [Quit: leaving]
<MrCooper> emersion: would that require multiple acquire points (another one for the Vulkan acquire point) for the same buffer attachment in the protocol?
<emersion> MrCooper: it should be possible to have a presentation timeline, which chains the Vulkan API acquire point and then the FIFO point
<emersion> such that the point submitted to the compositor depends on both
<MrCooper> what if the sync points immediately before and after the Vulkan acquire point are already used?
<emersion> the presentation timeline is completely independant from the Vulkan API's
<emersion> Vulkan user submits frame with timeline A and point 42
<MrCooper> k, good
<emersion> mesa transfers this point to timeline B, point 1
<emersion> then adds a new point 2 to this timeline for FIFO purposes
<emersion> and sends timeline B, point 2 to the compositor
<MrCooper> the same principle could be used for "not before" presentation timing as well
<emersion> yeah
<emersion> the obvious downside is that since the latching is client-side, there may be races
<emersion> but on the other hand it's as flexible as it gets
<MrCooper> and the compositor/kernel might be able to do a better job if they know the target ahead of time
<emersion> can always start with client side and offload some of it to the compositor in the future once we have more exts
<emersion> right
<MrCooper> agreed, good approach in general
<MrCooper> a Mesa implementation of FIFO using the v2 protocol seems like a good thing to use as one of the 3 implementations required by the protocol process
<emersion> my original plan was to implement the upcoming ext to present with timelines
<emersion> but yeah, that'd be a good alternative as well
<MrCooper> yeah, either or both seems nice
<MrCooper> swick[m]: ^ might be interesting to you
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<swick[m]> interesting idea
<swick[m]> but presentation-time feedback is still not the thing you should be using for FIFO semantics
<MrCooper> agreed, frame events are better for that
djbw has quit [Read error: Connection reset by peer]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<karolherbst> gfxstrand: but anyway.. it seems like copy_deref lowering also needs a similiar fix to that memcpy lowering as it can also explode in size with huge arrays
<pq> USB subconnector type...
<pq> maybe USB-C becomes a new top-level connector type, and then it has sub-types HDMI (dongle), DP (dongle), DP-alt (USB-C alternate mode or what is it?), etc.?
<pq> or should dongles be more MST like nowadays?
<pq> i.e. dynamically create MST connectors - but that might be confusing
<emersion> pq, will break existing user-space
<pq> which suggestion, how?
<emersion> existing DP connectors, which are physically USB-C, can't have their type changed
<pq> d'oh
<emersion> breaks compositor config files etc
kts has joined #dri-devel
<emersion> we could have a cap or something, but not sure it's worth it
<emersion> we'd probably want a prop anyways…
<emersion> to be able to expose the exact USB-C connector device
<pq> connector props to supercede all the current "connector type" fluff?
<emersion> e.g. a "usb_device" prop with "5-2:1.1"
<pq> sounds good at first hand
<emersion> we could have a "type" property which supersedes the type field, yeah
<emersion> but we need to clearly define it
<emersion> (and that wouldn't link to the USB device)
<pq> it might link... depending on how it's defined
<emersion> i'd expect a KMS enum
<emersion> if it's a string, "type" is probably not a very good name
<emersion> reminds me of the "PATH" stuff…
<emersion> "PATH" = "usb:5-2:1.1" is tempting
<pq> "USB-C:5-2:1.1,HDMI,VGA" for example, to say it's a physical USB-C and which one, using a dongle to convert to HDMI, plus another dongle to VGA. Assuming all that could be known, which I guess cannot always be.
<pq> a proper PATH with physical connector and add-on dongles sounds tempting
<emersion> oh the USB-C sysfs is pretty nice
<emersion> has properties like a "dock" bool
<pq> but I'm afraid I can't get much involved here, too far off of my current work
<emersion> > ls /sys/bus/usb/devices/1-0:1.0/usb1-port1/physical_location/
<emersion> dock horizontal_position lid panel vertical_position
<pq> not sure I even have USB-C personally anywhere
<emersion> i'm not sure baking the subconnectors into the path necessarily makes sense
<emersion> maybe…
<pq> if there is a converter dongle, it's on the signal path, so
<emersion> right, and a converter might have multiple output ports
<pq> sounds more and more like MST
<emersion> so DP → HDMI → VGA should probably have a different path from DP → HDMI → DVI
<emersion> or DP → DVI → VGA
<pq> that would make sense to me
<emersion> (assuming there is a HDMI converter that has either VGA or DVI output here)
<emersion> (or a DP converter which can do either HDMI either DVI)
<emersion> or*
<pq> but if a converter has multiple output ports, then shouldn't each one be exposed as a separate connector? Maybe not, if only one can be used at a time, but how do you then... update the path based on which one is connected?
<pq> assuming the converter even tells us that to begin with
<emersion> what do you mean?
<emersion> KMS props can be updated
<pq> I'm just thinking from end-user perspective: you have a port on the computer, and you plug in a thing that has multiple different types of ports. How do you represent that in UI?
<emersion> ah, so you're saying that ideally we know which availabe ports an adapter has?
<emersion> potentially even before anything is connected?
<pq> ideally yes, but I also wonder if that's feasible at all
<emersion> i'd be surprised if it was
<emersion> i'd be surprised if we can figure out the DP → HDMI → VGA case even
<jannau> I think USB-C/dp-altmode converters with multiple outputs are using DP MST
<emersion> DP-MST has a native concept of tree, but for anything else i don't think so
<emersion> jannau: yeah, we're wondering about non-DP stuff
<pq> the connector prop should be designed around the most flexible/complex case, and anything else that doesn't have all the info just reports whatever
<emersion> agreed
<emersion> (cc lumag, see the whole discussion above)
<zamundaaa[m]> pq: it's not necessarily that easy, as you're requiring everyone to put all the info in from the beginning. You can't change the prop for a given hardware setup if it's used by userspace as a port identifier
<zamundaaa[m]> So if you find out you can get more information later, you'd need yet another property to do that without breaking existing userspace
junaid has joined #dri-devel
<pq> true
<pq> so we'd actually need a property with an array of strings, so better ones can be added without deleting old ones... uhh
<pq> that problem is universal though, and always present; we're thinking of a new prop because we can change the old stuff, and that is a one-off fix. Once the new prop becomes broken the same way, we'd need yet another prop for the same reason.
<pq> *we cannot change the old stuff
<lumag> pq, I have a USB-C -> DP and HDMI (two output ports). Only one output ports is detected and works.
<pq> lumag, only one output port ever, or does it switch somehow?
<emersion> pq, yeah
<lumag> If I plug in HDMI and DP, only HDMI is detected
<lumag> and read
<emersion> DRM_CLIENT_CAP could be used to some extent
<emersion> and the kernel can shim the old APIs…
<lumag> So far we have support for single logical connector connected to several physical connectors, think about CONNECTOR_TV and respective subconnector types.
<emersion> hm, but a compositor is not very likely to be able to ever upgrade
<lumag> emersion, why?
<emersion> so yeah, need access to all variants, old and new
<pq> emersion, I wonder if the shimming will need to be per-driver, too
<emersion> lumag: because configuration files store the prop value
<lumag> true
<emersion> pq, could definitely happen yeah
<emersion> driver exposes a short string, then realizes it can expose more
<lumag> emersion, what about exposing USB connectors and a shim DP connectors?
<lumag> Just for AMD and intel
<emersion> what do you mean by "shim" exactly?
<lumag> lightweight aliases
<lumag> I haven't looked into corresponding drivers though.
<emersion> so user-space would see DP for Intel/AMD?
<emersion> but USB for everybody else?
<emersion> that doesn't sound great
<lumag> emersion, so user space would see USB for everybody, and aliasing DP for intel/AMD
<emersion> we could have CLIENT_CAP_USB_CONNECTOR or so
<emersion> so user-space would see two connectors, one USB and one DP, which are actually the ame?
<emersion> same*
<lumag> yep
<emersion> that sounds like it would cause many issues
<zamundaaa[m]> it definitely would
<gfxstrand> karolherbst: Yes, lower_var_copies needs something. I think what it needs is a threshold at which it emits memcpy().
<emersion> user-space would not know these are the same, and would try to drive each indepdendantly
<gfxstrand> karolherbst: Hrm... Actually that might not be tractable...
<gfxstrand> It probably needs a loop threshold instead
<lumag> true
<lumag> emersion, pq: I don't like the idea of 'path' including the USB path. It might change from boot to boot.
<zamundaaa[m]> emersion: regarding CLIENT_CAP_USB_CONNECTOR, that would not be a good idea. We need the old identifier as well as the new one
<emersion> lumag: really?
<pq> lumag, USB path is not a physical path?
<emersion> i thought usb path was physical
<lumag> emersion, pq. it includes bus id. And bus id can change depending on the probe order
<pq> well, replace that with something that is a physical path
<emersion> "The bus on each new host controller gets the next available bus number."
<lumag> yes
<emersion> that's a good point
<emersion> lumag, do you know if there is something else which doesn't change?
<emersion> something to represent a purely physical path for USB?
<lumag> emersion, no. We can create 'something', but it will not map to the actual system property.
<lumag> VID/PID do not change, but then we don't have a clear way to distinguish between several similar dongles
<lumag> typec path?
<emersion> we'd want something to identify "the upper-left USB port on this USB dongle"
<emersion> which doesn't change
<lumag> emersion, the problem is that there can be no _USB_ in case of a DP dongle
<emersion> AFAIK DP has such a concept
<lumag> which one?
<emersion> "the upper-left DP port on this DP dongle" as a stable identifier
<emersion> or maybe not and we've misunderstood the PATH prop the whole time?
<emersion> (also cc vsyrjala)
<jannau> device tree based systems might have labels on ports, the apple silicon systems all have something like 'label = "USB-C Left Front";" the usb-c/4 ports la
<emersion> jannau: is this exposed via sysfs with "physical_location" i mentioned earlier?
<lumag> emersion, what about something completely different for the DP: something like 'protocol' or 'bearer'. Which can be 'native', 'USB' or 'HDMI' (only for dual-mode ports)
<lumag> pq ^^
<gfxstrand> karolherbst: Okay, I've added a max unroll length to lower_var_copies as well
<pq> are we trying to solve the path problem (which has value in its own right), or just the connector type problem without path?
<emersion> in the case of HDMI, the subconnector would be HDMI already i think?
<jannau> I think all usb-c dp-altmode converters expose a BILLBOARD usb device
<gfxstrand> karolherbst: It's not amazing on arrays of arrays but it's better than what we have now
<emersion> pq, well they interact somewhat, so trying to see if there's a good solution to both, or if the solution should be separate
<lumag> jannau, not all
<pq> yes, I too think they interact
<lumag> it is an option, not a requirement
<lumag> and in some cases they disappear after DP altmode being negotiated
<pq> and I suspect that solving path would be an answer to the type question, but not vice versa.
<emersion> yes
<zamundaaa[m]> I don't think having the connector type in the path would be important. All I want to use the path for is as a fallback when monitors have broken EDID
<jannau> I don't see the label exposed in obvious places in /sys
<emersion> my immediate goal is to be able to expose strings such as "Samsung SyncMaster via HDMI and USB-C Left Front" to users
<zamundaaa[m]> For me, the connector name is only relevant because it gets shown to the user. Other than that I don't care about it
<emersion> you can hide it from the user if you can figure out that it's USB-C
<zamundaaa[m]> emersion: if we can get nice computer-side port names that would be great. I have doubts we can get that on most hardware though
<emersion> zamundaaa[m]: jannau said it's in device tree at least
<lumag> emersion, it is not required.
<emersion> sure
<lumag> We don't have labels on msm
<emersion> but when it's here, nice to show to users
<lumag> emersion, I don't think it is a part of DT spec
<lumag> or schema
<pq> If one can tell an end user which port a thing is a la "third from the left, in the back" etc. then that in itself is a persistent port ID, and therefore equivalent to a path. But the information does not always exist.
<pq> Sounds like we have three different things: path, end-user location, and connector type.
<zamundaaa[m]> Should these two things maybe be split? One thing for showing to the user, explicitly not guaranteed to be persistent, and one actually persistent ID with compatibility guarantees
<jannau> lumag: it is part of bindings/connector/usb-connector.yaml
<lumag> jannau, ack, excuse me then
<emersion> i don't think we'd want KMS to generate end-user strings
<lumag> I remembered krzk removing some of the labels from 410c DT
<zamundaaa[m]> Not end user strings, just a path that the compositor can convert into usable (and translated) strings
<emersion> these can be generated by the compositor from just the USB ID
<lumag> if there is a usb ID
<emersion> there is always a USB ID for USB devices
<lumag> emersion, if there is a USB device
<zamundaaa[m]> emersion: a split would be important imo because then you can add user-visible information later on, without breaking config files
<emersion> lumag: sure
<lumag> I have dongles w/o USB
<lumag> or with the USB disconnecting after altmode is negotiated
<emersion> that's a fun one
<lumag> emersion, it is a part of DP capabilities VDO:
<lumag> 7
<lumag> USB r2.0 Signalling Not
<lumag> 0 = USB r2.0 signaling may be required on A6 – A7 or B6 – B7 while in DisplayPort
<lumag> Used
<lumag> Configuration.
<lumag> 1 = USB r2.0 signaling is not required on A6 – A7 or B6 – B7 while in DisplayPort
<lumag> Configuration.
<emersion> so hm
<emersion> from the start when i said "USB device ID" what i really thought of was "USB port ID"
<lumag> I think you meant 'typec port id'
<emersion> ie, if a USB-C port is disconnected, some unique identifier for this port
<emersion> yeah, maybe
<lumag> But I'm not sure whether amd and intel drivers maintain such link
<emersion> so
<emersion> ^ what this does is link to the device, right? not the port?
<lumag> Yes
<emersion> so the link doesn't exist if there is no connected device?
<lumag> And single device can have two ports
<lumag> s/two/multiple/
<emersion> … wait, what? :o
<lumag> E.g. I have:
<lumag> lrwxrwxrwx 1 root root 0 Aug 12 23:47 /sys/class/typec/port0 -> ../../devices/platform/USBC000:00/typec/port0
<lumag> lrwxrwxrwx 1 root root 0 Aug 12 23:47 /sys/class/typec/port1 -> ../../devices/platform/USBC000:00/typec/port1
<lumag> there is a single UCSI device, two USB-C ports.
<lumag> (for the reference, Lenovo p53s)
<emersion> what is UCSI?
<lumag> A spec for the ACPI Type-C port configuration and management
<emersion> but in the specific case of USB for displays, can this happen stiull?
<lumag> see drivers/usb/typec/ucsi/
<lumag> Yes. Both USB_C ports are capable of a DP
<emersion> can i connect my screen with 2 USB-C cables?
<emersion> will this show up as one KMS connector, or 2?
<emersion> so it's not a tree, it's a graph?
<lumag> Hmm, if you connect your monitor using two cables, you'll see two different connections.
<lumag> For example, here I have:
<emersion> which means two KMS connectors?
<lumag> DP-1 - port0 'native' DP
<lumag> DP-2 - port1 'native' DP
<emersion> okay, phew
<lumag> DP-1-1 / DP-1-2 / DP-1-3 - port0 'docked' DP connections
<emersion> i was reconsidering my life choices for a sec
<emersion> what's important to me is that one KMS connector maps to a single USB-C port
<lumag> Yes
<emersion> *each KMS connector
<emersion> alright, so to sum things up a bit, a think we have the following options:
<emersion> - add a "USBC_PORT" prop, backwards compatible, need to check amd/i915
kts has quit [Ping timeout: 480 seconds]
<lumag> emersion, sounds good to me
<emersion> - add USB connector type, needs DRM_CLIENT_CAP_USB_CONNECTOR, doesn't expose the USB-C port so not enough for all use-cases
<emersion> - figure out a way to expose a PATH prop, needs a lot more investigation, not sure possible at all
<emersion> (plus these backwards compat questions)
<emersion> lumag: additional question, how useful is the USB-C port? i'd assume i can walk the tree from there, discover connected USB devices, etc?
<lumag> emersion, yes
<emersion> cool
<zamundaaa[m]> ohh then we could maybe detect if a touchscreen is connected to a given screen?
<emersion> aha
<emersion> zamundaaa[m]: i think it depends on a lot of stuff
<emersion> like, if you have a USB hub…
<lumag> emersion, the port itself is not a part of the USB topology
<emersion> for that use-case you'd maybe be more interested in the USB device
<lumag> it lists two USB busses
<lumag> s/busses/routed ports/
<emersion> not 3?
<lumag> emersion, compare this with https://pastebin.com/SHJvbPLh
<emersion> port0.0, port0.1, port0.2?
<lumag> No. port0.0, port0.1 and port0.2 are altmodes
<emersion> i see
<lumag> /sys/class/typec/port0/port0.0/svid:17ef
<lumag> port0.0/svid 17ef
<lumag> port0.1/svid 8087
<lumag> port0.2/svid ff01
pixelcluster has quit [Ping timeout: 480 seconds]
<lumag> emersion, I'd say:
<lumag> - we need connector -> type-c sysfs port link
<lumag> - probably the best option would be to encode type-c port into PATH property.
<emersion> i don't think we can re-use PATH here
<emersion> already used by DP-MST
<lumag> (unless it breaks userspace expecting stuff like 'mst:103-2')
<lumag> "Connector path property to identify how this sink is physically connected."
<lumag> But I'm not sure if 'typec:1' will break userspace expecting 'mst:foo'
<emersion> also is the typec port number persistent?
<emersion> or can it change across reboots/upgrades?
<lumag> On devices I have here it is persistent
<emersion> lumag: what if there is typec *and* DP-MST
<lumag> heh, mst:103-2 is such example
<lumag> connector '103' is the base connector
<emersion> hm.. do you mean '103' is the KMS connector ID, or something else?
<emersion> KMS connector object ID, i mean
<lumag> yes, connector ID
<lumag> xorg will silently skip PATH if it doesn't start with 'mst:'
<mceier> lumag: the function that calls parse_path_blob has other fallbacks - https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L3278
<emersion> it doesn't seem so
<emersion> Connector 5 with object ID 114 has "mst:92-1"
<lumag> yes, which tells that it is going through Connector 1 (with ID 92)
<emersion> eh, but 92 is another connector…
<emersion> ouch…
<emersion> that means it's not a stable identifier at all
<emersion> pq ^
<lumag> well, connector IDs are stable in 99% of cases
<emersion> hm no
<lumag> why?
<emersion> upgrades create new props, which share the same namespace, for one
<emersion> driver probe order
<emersion> etc
<lumag> Ah.
<lumag> driver probe order will not change it, since each device has its own namespace
<emersion> okay, that makes PATH mostly useless
<lumag> But for the new props, it's true
<emersion> hm, possible
<emersion> i don't remember
<lumag> I'd say, PATH is semi-dynamic.
<lumag> In other words it can not be used as a static reference, but it can be parsed to produce one.
<emersion> that's not a good thing to store in a config file
<emersion> hm
<emersion> but what are the numbers after the parent connector ID?
<lumag> emersion, that's why xorg parses it to produce sensible names
<emersion> are these dynamic or not?
<lumag> MST port number
<lumag> static
<emersion> ok, nice
<lumag> On the devices i have here it corresponds to the physical port
<lumag> emersion, I'd say PATH = 'typec:%d' solves our issues.
<emersion> i don't think so
<lumag> We can parse it and then generate 'USB-DP-%d' connector names
<emersion> a connector can be both Type-C and DP-MST
<lumag> Then the base connector will have Type-C and next connector will be DP-MST
<emersion> to not regress user-space, PATH needs to be "mst:<something>" for all DP-MST connectors
<emersion> hm
<emersion> i see
<lumag> In my case I'll have DP-1 with PATH='typec:0', and DP-4 / DP-5 / DP-6 with PATH='mst:103-#'. Xorg then renames DP-4/5/6 to DP-1-1, DP-1-2, DP-1-3
<lumag> And correspondingly DP-2 with PATH='typec:1' (or vise versa) and DP-something renamed to DP-2-1, DP-2-2, etc.
<lumag> The only issue I foresee is SlimPort, the legacy/obsolete DP-over-micro-USB.
<emersion> that sounds good to me, with the caveat that i don't understand things deeply enough to say for sure whether this is a good use of PATH, or an abuse
<emersion> well this one would be completely different no?
<emersion> i don't know if anyone cares enough to address it
<emersion> by "completely different", i mean probably PATH with "usb:<something>"
<lumag> emersion, yep
<lumag> at least it sounds logical then
<emersion> and the same would apply for other display-over-older-USB things
<lumag> It is supported by drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c, which I hope to try on Nexus7-2013 at some point
<emersion> like GUD
<lumag> ok.
<lumag> I can then scratch an RFC during the weekend and send it to dri-devel
<emersion> nice
<emersion> i can write the user-space
<lumag> :-)
greenjustin has joined #dri-devel
<lumag> mceier, yes, but the fallbacks are basic - type + index (not the object ID)
<emersion> mceier, i don't see your message
<mceier> lumag: yes, you can ignore me, since I donn't really know the context ;)
<lumag> emersion, it was '<mceier> lumag: the function that calls parse_path_blob has other fallbacks - https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L3278'
<emersion> and now i do
<emersion> oh, in the backlog - nevermind!
<emersion> i thought this was another case of matrix users
<mceier> :)
bmodem has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
junaid_ has joined #dri-devel
junaid has quit [Read error: Connection reset by peer]
junaid_ has quit []
<lumag> jani, jannau, emersion, airlied: another DP-related topic. I'm trying to understand a way for https://patchwork.freedesktop.org/series/120395/ to land.
<lumag> It is core + intel, but it is required to enable additional part of DP on msm platforms
yuq825 has left #dri-devel [#dri-devel]
ishitatsuyuki has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ishitatsuyuki has joined #dri-devel
<pq> emersion, PATH property for DP-MST is not persistent at all? Whee. Well, it just means more parsing, don't simply save the PATH string as-is. Replace the conn ID with a proper path.
<karolherbst> gfxstrand: cool, will give it a try. I have a few patches around to reorder some of the lowering, because I'll need it for program variables as well. Anyway, seems to work either way now.
paulk-bis has quit [Ping timeout: 480 seconds]
<alyssa> Do we have any common code for handling ADJACENCY in the absense of a geometry shader?
<alyssa> other than nir_create_passthrough_gs, I guess
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Omax is now known as Guest9285
<alyssa> hmm, gl-3.2-adj-prims passes, I wonder why the CTS doesn't
Omax has joined #dri-devel
Guest9285 has quit [Remote host closed the connection]
pixelcluster has joined #dri-devel
kts has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
yyds has joined #dri-devel
JohnnyonFlame has joined #dri-devel
mbrost has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
CounterPillow has quit [Quit: Bye.]
CounterPillow has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
<dottedmag> How is GBM_BO_USE_RENDERING really used? In libgbm DRI backend the only use of this flag is to check that GBM_BO_USE_CURSOR and GBM_BO_USE_RENDERING are not specified at the same time.
rsripada has quit [Quit: No Ping reply in 180 seconds.]
rsripada has joined #dri-devel
<alyssa> got it. 2 bugs in nir_create_passthrough_gs,
Company has joined #dri-devel
<alyssa> MR coming soon
<alyssa> kusma: zmike: It looks like nir_create_passthrough_gs wants the VS/TCS but doesn't actually use it, it just uses the shader info
<alyssa> Is there a compelling Zink reason it's done like this?
<zmike> you'd need to ask pac85 but he's not on irc
<alyssa> Why should the passthrough GS be tied to the shader, as opposed to just the context/screen?
<alyssa> who is pac85?
<alyssa> kusma wrote this code
<zmike> antonino
<zmike> just create a ticket
<alyssa> Alright
<alyssa> It looks like it would be sufficient to pass in (outputs_written, has_transform_feedback_varyings, xfb_stride, xfb_info) instead of the whole shader
<zmike> could be
<alyssa> in the common case where there's no GS that's just outputs_written
<zmike> on my side there's no requirement for it being the way it is
<alyssa> which means you can reuse passthrough GS's for unrelated VS's as long as they write the same outputs
<alyssa> which seems.. potentially good?
<zmike> but this is emulation code that I don't (personally) support or deal with so you'll want to ask in the ticket
<alyssa> yeah fair enough
<alyssa> I'm considering the incredibly dubious choice of using a passthrough GS anytime XFB is used
<alyssa> but I digress :~P
<alyssa> oh, hm, this might be tricky without lowered I/O though
* alyssa may fork create_passthrough_gs for a lowered I/O-only version if this can't be fixed with derefs
<zmike> just convert it to lowered io?
<alyssa> oh that MR landed, nice :)
<zmike> the only caveat, as I replied, is that variables/types do have to exist and be correct
<zmike> which is probably not a huge ask?
<zmike> but who knows what your needs for this are
<alyssa> certainly I don't
<alyssa> Hmm
<alyssa> Now I'm wondering if it wouldn't be better to handle adjacency in the VS
<alyssa> meh, this is a totally stupid edge case that apps won't hit, not worth the combinatorics
Duke`` has joined #dri-devel
junaid has joined #dri-devel
<DemiMarie> pq emersion: from a security perspective, Qubes really wants physical paths determined by where a user plugged in their device, so that a malicious device cannot spoof another device.
<emersion> not sure i understand the threat model
<emersion> lumag: ah btw IGT expects "has PATH prop == DP-MST"
<emersion> would be nice to stop making that assumption
donaldrobson has joined #dri-devel
heat has joined #dri-devel
benjamin1 has joined #dri-devel
yyds has quit [Remote host closed the connection]
<alyssa> please & thank u
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
greenjustin_ has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
greenjustin has quit [Ping timeout: 480 seconds]
<DemiMarie> emersion: Qubes OS considers external peripherals, such as USB devices, to be untrusted by default (that’s why we have sys-usb). Ideally DisplayPort alt mode would be limited to trusted devices, though that is not currently implemented. For it to be possible to implement, though, the ID needs to be something a malicious device can’t spoof, as otherwise a malicious device could impersonate a trusted one.
lynxeye has quit [Quit: Leaving.]
kts has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
danilo has joined #dri-devel
danilo has quit [Remote host closed the connection]
dakr has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
dakr has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest9297
macromorgan has joined #dri-devel
Guest9297 has quit [Ping timeout: 480 seconds]
donaldrobson has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit []
vliaskov has quit [Remote host closed the connection]
idr has joined #dri-devel
<idr> Anyone have issues with 'ninja test' hanging in 'mesa:util / util_tests'?
junaid has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
Leopold_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Leopold__ has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
Danct12 has joined #dri-devel
junaid has joined #dri-devel
<DavidHeidelberg[m]> idr: do you have today `main`?
<idr> Yeah... and I can reproduce it on my main system back over 1000 commits.
<idr> But it only seems to happen on that system.
<DavidHeidelberg[m]> this issue or different one?
<idr> hm...
<idr> Different, but possibly related.
<idr> It looks like it times out in SparseArrayTest.Multithread.
<idr> So, maybe not related... unless the cache test is also multithreaded.
mbrost_ has quit [Ping timeout: 480 seconds]
<idr> There is something janky going on.
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
Danct12 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
digetx has quit [Ping timeout: 480 seconds]
Leopold___ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
konstantin_ has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
idr has quit [Remote host closed the connection]
konstantin has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
digetx has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
Haaninjo has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
apinheiro has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
benjamin1 has joined #dri-devel
crabbedhaloablut has quit []
rsalvaterra has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
mattrope_ has quit [Remote host closed the connection]
benjamin1 has quit [Ping timeout: 480 seconds]
idr has quit [Remote host closed the connection]
mocoo has joined #dri-devel
eukara has quit []
benjamin1 has joined #dri-devel
idr has joined #dri-devel
<idr> DavidHeidelberg[m]: Reverting glibc from glibc-2.37.9000-14.fc39 to glibc-2.36-9.fc37 has "fixed" the problem.
eukara has joined #dri-devel
heat_ has joined #dri-devel
<DavidHeidelberg[m]> ugh, some extra Fedora patches or just the glibc bump to 2.37?
<idr> Dunno.
<idr> I have a commit that also "fixes" it, but it make it run much more slowly on systems that don't have the problem.
heat has quit [Read error: No route to host]
<HdkR> https://sourceware.org/bugzilla/show_bug.cgi?id=30723 Known regression in glibc I'm pretty sure
<DavidHeidelberg[m]> ^ then I guess we just have to wait a week or two for this issue to disappear hopefully?
rsalvaterra has joined #dri-devel
<DavidHeidelberg[m]> zmike: KHR-GL46.layout_binding.sampler2D_layout_binding_texture_ComputeShader took down by `free(): unaligned chunk detected in tcache 2` is that something you aware?
<zmike> it's been on my list but the list is long
eukara has quit [Remote host closed the connection]
greenjustin_ has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
<idr> HdkR: That sounds very much like the issue.
<idr> I'm glad that I didn't have to try to write a good bug report for it. :)
<idr> Wow... DJ Delorie is a name I haven't heard in many years... since I did DOS programming in the mid 90s.
<HdkR> Somewhat luckily I was pointed to that issue just a day or two ago
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
<DavidHeidelberg[m]> zmike: u know, that's enough, worth adding into flake list?
<zmike> suer
heat_ has quit [Remote host closed the connection]
jimc has quit [Remote host closed the connection]
shashanks__ has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
mattrope has joined #dri-devel
pcercuei has quit [Quit: dodo]
kts has quit [Quit: Konversation terminated!]