heat has quit [Read error: Connection reset by peer]
Lucretia has quit []
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #dri-devel
Lucretia has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
blue__penquin has joined #dri-devel
adjtm has quit [Quit: Leaving]
blue__penquin has quit []
adjtm has joined #dri-devel
blue__penquin has joined #dri-devel
boistordu_ex has joined #dri-devel
blue__penquin has quit []
Net147_ has joined #dri-devel
Net147_ has left #dri-devel [#dri-devel]
Net147 has joined #dri-devel
<Net147>
is it possible to have a separate DRM fd for each connector on a device?
boistordu_ex has quit [Ping timeout: 480 seconds]
boistordu_ex has joined #dri-devel
<imirkin>
Net147: you mean have separate processes control modesetting on each connector?
<Net147>
imirkin: same process, different threads
<imirkin>
i ... would assume so? you can just dupfd() N times
<imirkin>
of course things like atomic modesets require having the full info
<Net147>
imirkin: the problem is that one thread is calling drmHandleEvent with its own handler for one connector and that is messing with the event handling for a connector in different thread
<Net147>
imirkin: dupfd gives different FD number?
<imirkin>
dupfd does make a different fd number
<imirkin>
not sure how that translates over to drm events
<Net147>
imirkin: thanks, I will try it
<Net147>
imirkin: can I limit drmHandleEvent to handle events for only a single connector?
FireBurn has quit [Ping timeout: 480 seconds]
<Net147>
imirkin: perhaps using DRM leases...?
ppascher has joined #dri-devel
<mareko>
bnieuwenhuizen: does ChromeOS use implicit sync, explicit sync, or even sync files?
orbea1 has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
orbea1 has quit []
orbea has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
blue__penquin has joined #dri-devel
<Net147>
imirkin: using DRM leases seems to work well
<daniels>
hakzsam: not CI, just fd.o infra issues, being worked on as we speak
<hakzsam>
ok, thanks for the info
lynxeye has joined #dri-devel
<bnieuwenhuizen>
mareko: a mix of implicit sync (for things like libva) and explicit sync using sync_files (mostly due to Android but also for e.g. scanout in Chrome)
<pq>
imirkin, dupfd on DRM fd does not give you anything new/more. Well, maybe more confusion, perhaps.
<pq>
imirkin, dupfd just gives you a new file descriptor, while everything DRM hangs off the file *description* which is still the same for all fds leading back to the same open() call. Even if the fd ended up in another process, it's still the same.
<Net147>
pq: I am using DRM leases and it is working fine
<pq>
Net147, cool. Just be prepared to meet random failures with KMS, as KMS hardware state is really per-card, not per-connector.
<Net147>
pq: what kind of failures?
<pq>
Net147, like in some cases the driver needs to access more resources that you would expect, which may mean stomping over stuff you maybe wanted to use for another connector.
<Net147>
pq: is there an example of this happening in the wild?
<pq>
Net147, yes: memory bandwidth limitations, needing multiple hw crtcs to drive a single connector under the hood, ...
<pq>
all the reasons why atomic modesetting exists, where you can set everything on the card in one go, and it either works or does not work deterministically rather than randomly.
<pq>
Net147, of course, there are hardware and use patterns where the probability of such failures is low enough for practical use.
<pq>
like a display server leasing out a crtc+encoder+connector to an app, and if the display server gets in trouble because of the app, it can revoke the lease and try again
<pq>
the app also needs to be prepared to handle failing modeset, but once it has a mode set, simply flipping buffers should be fairly safe
<pq>
the risky situations are when new connectors or KMS planes needs to taken into use, or if you change your buffer format/modifier
<Net147>
pq: I only intend to set up once and then only flip buffers
<Net147>
pq: not reconfiguring
<pq>
I would assume that is quite safe
pcercuei has joined #dri-devel
<pq>
then again, I'm not sure why you want each thread to be making their own KMS calls
<pq>
you could concentrate all KMS handling to a single thread that talks with the other threads doing stuff
<danvet>
yeah leases for threads make fairly little sense, they're meant as some form of isolation for another process
<danvet>
I guess the benefit is that you get a per-thread drm_events queue
<Net147>
danvet: yes, I am using it to get a per-thread drm events queue
hofer_jn has joined #dri-devel
blue__penquin has quit [Remote host closed the connection]
<hofer_jn>
Hey! I wonder where I can find out whether "AMD Radeon Pro WX 3200 4 GB" is supported by Mesa.
tomba[m] has quit []
tomba[m] has joined #dri-devel
blue__penquin has joined #dri-devel
tomba[m] has quit []
<JoshuaAshton>
It's just Polaris so I think it should?
tomba[m] has joined #dri-devel
<hofer_jn>
Thanks @JoshuaAshton. So you would expect that it *just works* on machine with an updated fedora. Without having to install proprietary drivers? :)
<JoshuaAshton>
hofer_jn: No guarantees but I would expect that
<hofer_jn>
Sure :)
<hofer_jn>
Thanks!
pochu has joined #dri-devel
blue__penquin has quit [Remote host closed the connection]
<tomeu>
probably related to "[0m[31mERROR - Failure getting run results: parsing results: Reading from dEQP: timed out waiting for fd to be ready (See \"//results/c25.r1.caselist.txt\")"
<tomeu>
maybe anholt has a better idea of what that means?
Lightkey has quit [Ping timeout: 480 seconds]
pekkari has quit []
Lightkey has joined #dri-devel
ubitux has joined #dri-devel
mwk has quit [Remote host closed the connection]
mwk has joined #dri-devel
mosasaur has joined #dri-devel
Anorelsan has quit [Quit: Leaving]
rib has joined #dri-devel
sumits has joined #dri-devel
pekkari has joined #dri-devel
sumits has quit [Ping timeout: 480 seconds]
Lucretia-backup has joined #dri-devel
Lucretia has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
<mosasaur>
I want a big framebuffer, and have xservers on different boxes behave as windows in that framebuffer. Like the ultimate inception. Does that even make sense to anyone here?
<mosasaur>
I mean, I tried in #x2go, and even though they seemed to understand the concept, it got kind of quiet after that
<imirkin>
pq: yeah, i know. but he was asking for another fd. so ... yeah. multiple open's weren't going to work either.
xp4ns3 has quit []
tfiga has joined #dri-devel
kgz has joined #dri-devel
sneil has quit []
Karyon has joined #dri-devel
sneil_ has joined #dri-devel
pekkari has quit []
pekkari has joined #dri-devel
<zmike>
mareko: if you get time, my vbuf overflow MR needs a review
pekkari has quit []
<DPA>
mosasaur: I think there's xnest and xephyr for nesting X servers.
ubitux has quit [Quit: WeeChat 3.1]
ngcortes has joined #dri-devel
<mosasaur>
DPA: yeah, I'm using xephyr for some stuff. However I never got that working with xdmx or such
<mosasaur>
and xdmx is not exactly what I like, though it would come close
<mosasaur>
but I want to multihead using xservers on different boxes
<imirkin>
mosasaur: how is dmx not what you want?
<imirkin>
i thought that was the thing for video walls
idr has quit [Ping timeout: 480 seconds]
<mosasaur>
imirkin: I'm sitting in front of 4 monitors. Two to the sides, they are rotated 90 degrees. The other two are in the middle, one above the other. I don't think xdmx plays well with rotated monitors, or monitors with different resolutions
ubitux has joined #dri-devel
<imirkin>
mosasaur: hmmmmm ... certainly not randr-style rotation
<imirkin>
not sure if there's any other way to rotate than with randr
alanc has quit [Quit: Leaving]
<imirkin>
and yea, no clue about multiple resolutions
<mosasaur>
so, I'd need one of my boxes, the fastest one, to make me a big framebuffer, and let the other othe boxes use slices of that, like windows into that framebuffer
<imirkin>
yeah, i think it's pretty clear what you want
alanc has joined #dri-devel
<mosasaur>
imirkin: great, that's progress at least :P
<mosasaur>
everything starts with the concept
<imirkin>
i believe dmx was the thing to address this general desire
<imirkin>
if it doesn't handle some aspect of what you want, improve it?
alanc has quit []
alanc has joined #dri-devel
<mosasaur>
sure, but it's kind of moving slow. Meanwhile we have things like xpra, and x2go which use some kind of related stuff, with x2go even having some kind of better compression for moving framebuffer data around?
<mosasaur>
I used to program in C a lot, but then moved to python, would prefer some kind of abstraction that would do the heavy lifting in C or who knows, rust or something, but do most of the logic in python
<imirkin>
alyssa: yeah ... 0 planes isn't too useful. (or perhaps -1 due to some error)
<mosasaur>
xdmx feels scary to me
<imirkin>
mosasaur: yeah, coz if xdmx were written in rust it wouldn't be scary at all
<mosasaur>
maybe I'm wrong and I could still do stuff there
<mosasaur>
but my C is very rusty
<imirkin>
on the bright side, C is a trivial language, should take no more than 30 mins to de-rust?
<mosasaur>
I mean seldom used anymore :P
<alyssa>
Your C might be Rusty
<alyssa>
but my Rust is rather C-like :(
<imirkin>
anyways, i strongly doubt anyone has used dmx in the past 5-10 years.
<imirkin>
so if it's not you, it's not gonna get done
<imirkin>
most people just get a graphics card which can support 4 monitors
<imirkin>
and avoid the oodles of problems that come even from having 2 graphics cards in one system
<imirkin>
much less graphics cards distributed over multiple machines
<mosasaur>
yea, have been looking at some cheap machine with 4x HDMI
<alyssa>
geez modifiers are so broken on panfrost right now
<imirkin>
i think ASUS makes a NVIDIA GT 710 with 4x HDMI and passive cooling
<imirkin>
not that i'd recommend NVIDIA
<mosasaur>
but even so, I like the idea of having a framebuffer that is bigger than a screen, or many screens
<imirkin>
but AMD boards tend to be pricier
<imirkin>
(at the low end)
<mosasaur>
imirkin: thanks, another machine I'll want to look up
<mosasaur>
don't you want to liberate the framebuffer from being bound to a screen size, some kind of cognitive leap of the imagination
<imirkin>
huh? framebuffer can be any size you want
<imirkin>
you can have virtual desktops (iirc)
<imirkin>
which basically lets you pan some larger desktop
<mosasaur>
yes, that idea is very close, just not distributed yet
<imirkin>
if you want distributed, there's dmx :)
<mosasaur>
and the desktops can only switch, not freely move around in the framrbuffer
<imirkin>
no, i'm talking about a feature where you freely move around
<imirkin>
iirc it's called virtual desktop
<imirkin>
but i don't fully remember
<imirkin>
i last used it in 1999
<imirkin>
so my memory's slightly faded on the details
<mosasaur>
yes, for me it goes back a long way too, when I was doing this on a atari st
<imirkin>
you can specify modes for a monitor, but you can also specify a desktop size
<imirkin>
and when you change modes, the desktop size doesn't change
<imirkin>
so you can pan around
<mosasaur>
which makes it so frustrating that we don't have it now, because the screen is not contiguously memory mapped anymore, or something
<imirkin>
not sure what you're talking about
<imirkin>
X makes a single framebuffer
<imirkin>
of arbitrary size
<imirkin>
and each screen is a "view" into that framebuffer
<imirkin>
there can be additional copies away from that framebuffer, e.g. to handle rotation
<imirkin>
(since most GPUs don't support rotation natively)
<mosasaur>
hmmm, maybe all is not lost then
<alyssa>
it's all broken after all, it's all broken after all, it's all broken after aaaaaall, it's all broken after all!
Daanct12 has joined #dri-devel
<alyssa>
Program terminated with signal SIGKILL, Killed.
<alyssa>
not helpful gdb
<alyssa>
Is this even a driver issue? I have no idea
mosasaur has quit [Remote host closed the connection]
lemonzest has quit [Quit: Quitting]
Danct12 has quit [Ping timeout: 480 seconds]
<alyssa>
maybe my board is just that broken now
DanaG has joined #dri-devel
<Surkow|laptop>
:D
<Surkow|laptop>
just copy and paste your questions here
<DanaG>
Is anyone here familiar with the ASPEED DRI driver (ast)? On the last two boards I had with one (Supermicro x10sl7-f and x10slm+-f), I've had a problem where the iKVM goes unresponsive (black screen) after in DPMS for a while, and even a chvt or restarting GDM won't make it work again.
<DanaG>
I'm not sure whether it's a hardware problem, a BMC firmware problem, or a problem in the ast driver. I do see input make it through, but the remote KVM shows nothing. If it's just the Supermicro board(s), I'd consider replacing the one I still have with something else, but what if that something else has the problem, too?
<imirkin>
DanaG: it's pretty apparent from your question, but you're referring to the *drm* driver, not dri. (i have zero insight into your actual concern though)
<DanaG>
That's true, I didn't think of the distinction.
<imirkin>
[there is no ast dri driver]
<DanaG>
Heck, "ast" can't even be a PRIME output provider for a discrete GPU.
<imirkin>
if someone really wanted that, it could be arranged
<imirkin>
there's no hard reason it's unsupportable
sigmaris has joined #dri-devel
<imirkin>
just soft reasons
<imirkin>
DanaG: btw, you can force dpms on and off with 'xset dpms force off'
<imirkin>
if you want to test stuff out
<imirkin>
and you can do 'xset s off' to disable dpms
<imirkin>
not exacty solution for the underlying problem, but ...
<DanaG>
I'll have to see how to do that with either gdm or lightdm. I doubt DPMS even saves much power on this chip with no monitor connected.