karenw has quit [Remote host closed the connection]
karenw has joined #dri-devel
LeviYun has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
sassefa has joined #dri-devel
vliaskov has quit []
LeviYun has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.3.5]
nerdopolis has joined #dri-devel
sassefa has quit [Remote host closed the connection]
sassefa has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
pcercuei has quit [Quit: dodo]
Company has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
LeviYun has joined #dri-devel
vedranm_ has joined #dri-devel
vedranm has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
alane has quit []
alane has joined #dri-devel
Kayden has quit [Quit: -> hillsdale]
<DemiMarie>
Does playing restricted content require Wayland compositor integration?
heat has quit [Ping timeout: 480 seconds]
<Company>
something has to happen when I press PrntScrn
Omax has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
LeviYun has joined #dri-devel
leizhou has joined #dri-devel
Omax has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
leizhou has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Demi: yes, mostly
<zamundaaa[m]>
There's some embedded platforms where video playback is routed weirdly and is put in an underlay by the display hw
<zamundaaa[m]>
For those, the compositor "just" needs to punch a hole into the other planes, to make the video visible
<DemiMarie>
zamundaaa: Thank you! That doesn't apply to me, so indeed it is required.
LeviYun has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
<DemiMarie>
The reason I ask is that if playing restricted content won't work anyway, I'd rather just fail any attempt to use it.
alih has quit []
<DemiMarie>
There is no legitimate reason to use the functionality, so I want to block it (at the native context level) to reduce attack surface.
glennk has joined #dri-devel
<DemiMarie>
zamundaaa: What happens if someone tries to play back restricted content without the compositor knowing? Do they just get garbage displayed on screen?
<zamundaaa[m]>
Depends on how it's implemented in the hardware
<zamundaaa[m]>
Afaik the common thing is that you just get black though
<zamundaaa[m]>
But I don't have much experience on the topic, so that might be wrong
LeviYun has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
<Company>
Vulkan kills your device if you try to read restricted data, no?
<DemiMarie>
Company: in that case dmabuf import of a restricted buffer had better fail.
<DemiMarie>
In this case the compositor has no idea the buffer is restricted.
<Company>
reading the spec, it's an invalid usage and the behavior in those cases is undefined
<Company>
which usually means SEGV or other fun signals
leizhou has quit [Ping timeout: 480 seconds]
<Company>
in Vulkan you MUST always use the right protection flags for all accesses to protected data
<Company>
the only thing I didn't check is if import is allowed to fail
<Company>
but grep the vulkan spec for *_PROTECTED_BIT, it's named the same everywhere
<DemiMarie>
Company: how does one deal with imported buffers? I thought Wayland clients were not allowed to crash the compositor, and if they cab it's a security vulnerability.
<Company>
compositors make sure that the dmabuf is valid before importing it I would assume
<Company>
but no idea how they do that, I just write the clients
konstantin_ has joined #dri-devel
konstantin is now known as Guest2378
konstantin_ is now known as konstantin
Guest2378 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Judging by some old MRs on Mesa I just found, you actually get garbage out if you read from a restricted buffer without a matching context
<zamundaaa[m]>
And import does not fail in that case
<zamundaaa[m]>
That's for AMD and Intel, might not be generic
<DemiMarie>
zamundaaa: garbage out is acceptable from a security perspective.
<DemiMarie>
What matters is that it doesn't cause undefined behavior in the compositor.
<DemiMarie>
I think the spec is written that way because accessing restricted buffers without a proper context has no legitimate uses.
<Company>
usually, if the spec isn't clear on something, it's because the vendors disagreed on something
<mareko>
garbage out is the hw behavior, you get the same data that shaders get
<jfalempe>
Also I wanted to have drm_log works with fbcon, so that drm_log will display the boot logs, and when userspace is started, fbcon will take over, but currently the fbdev emulation takes the screen unconditionnaly just after driver registration.
<jfalempe>
sima: thx
<tzimmermann>
jfalempe, done
<jfalempe>
tzimmermann: thx too!
<tzimmermann>
jfalempe, that's a hard problem
RSpliet has quit [Quit: Bye bye man, bye bye]
<tzimmermann>
after the driver registered, it's there for use
<tzimmermann>
that is also the earliest time you could reliably use drm_log
RSpliet has joined #dri-devel
<tzimmermann>
you'd need the login prompt to tell the driver that there's now an input prompt waiting and thereby make it switch to the console infrastructure
<tzimmermann>
maybe console binding could solve that issue
<jfalempe>
yes that was my idea, to wait for the prompt before doing the probe in drm_client.
<tzimmermann>
but that's unrelated to drm
<tzimmermann>
rather install both clients (fbdev, log) and switch between them
<jfalempe>
how do you switch ? currently drm_log is registered first, so when fbdev emulation is initialized, it steal the display, and drm_log writes to its framebuffer, but it won't make it to the screen.
<tzimmermann>
jfalempe, there's drm_client_dev_restore() that picks a drm client
<tzimmermann>
upon restoring the kernel DRM client
<tzimmermann>
(if there's no userspace compositor)
<tzimmermann>
it's first-come-first-served
<jfalempe>
tzimmermann: thx I will look into that.
<tzimmermann>
it could select a client by some sort of priority
<tzimmermann>
but that might not be such a great idea after all
<tzimmermann>
the kernel fbcon really is special
<tzimmermann>
IMHO
<jfalempe>
yes, if it's too complex, I will just make drm_log not build if fbcon is enabled.
<tzimmermann>
personally, i'd not want to swap outputs after text-mode booting
<sima>
might need a few layers I guess
<jfalempe>
but that means you'll need userspace console, and a few other things, to really use drm_log.
<sima>
like give drm_log priority, but if there's fbdev chardev open, then give drm_fbdev priority
<tzimmermann>
jfalempe, exactly
<sima>
for fbcon we'd probably need to wire the "is userspace using this" all the way through vt->console->fbcon->fbdev->drm which is ... ugh
<tzimmermann>
but using drm_log is not a means in itself
<jfalempe>
sima: yes too much layers to go through.
<tzimmermann>
it might be better to write a drm console and kill fbdev-emulation entirely
<sima>
would still need to go vt->console->drmcon
<tzimmermann>
sima, no i mean don't do drm_log; do drm_con instead
<tzimmermann>
same as fbcon, but without all the fbdev inbetween
<sima>
hm yeah might work better
<sima>
and if someone wants to keep fbdev chardev around, there we know when it's in use
<jfalempe>
tzimmermann: I think we shouldn't do the same mistake as fbcon, I will prefer having console and log separated
<tzimmermann>
jfalempe, i see this as a desing mistake
<sima>
but then, just put the drm con in userspace where it should be, if we create a new one
<tzimmermann>
console input and output belong together
<tzimmermann>
there's no separation between 'log' and 'user'
<sima>
there is? dmesg-console vs vt-console
<tzimmermann>
sima, yes it's possible to control the messages that go to the console
<sima>
it's just that vt-console also cosplays as a dmesg-console, which is where all the pain starts
<tzimmermann>
but that's different from having a console that does not print console messages at all
<jfalempe>
if you have a shell, you can always run dmesg if you want to see the kernel message.
<sima>
yeah, dmesg randomly destroying my vim/screen/whatever shell tool is annoying :-)
<jfalempe>
I don't see the point in having kernel message flooding your terminal
<tzimmermann>
jfalempe, but there's a reason why some dmesg messages end up on the vt-console
<tzimmermann>
and changing that is also a significant change policy
<tzimmermann>
jfalempe, some users want to know when sometihng bad happens
<tzimmermann>
and that policy is controlable
<jfalempe>
you can run "dmesg -w &" to do the same ?
<tzimmermann>
breaking that seems like a recipe for flamewars and disgruntled users
<tzimmermann>
it's not about can-or-cannot
<jfalempe>
yes this is what I want to avoid.
<sima>
then I guess userspace console should emulate that, if it's needed
<tzimmermann>
it's about 'the kernel automatically tells me when a major error happend'
<sima>
but if we end up with CONFIG_VT=y still, it's a bit silly imo
xroumegue has quit [Ping timeout: 480 seconds]
<jfalempe>
the end goal is having CONFIG_VT=n, and we should find a way to get there step by step, without hurting users.
<tzimmermann>
jfalempe, and any userspace console would have to emulate the current behavior
<sima>
yeah for CONFIG_VT=n I think it's drm_panic + drm_log for early boot + userspace console that is close enough to the current thing
<tzimmermann>
keeping the dmesg logs entirely off the console is not going to fly with many people
<jfalempe>
it would be nice to enable drm_log and keep fbcon, and then switch to userspace console. but that looks too complex.
<jfalempe>
tzimmermann: yes but that should be possible in userspace.
<jfalempe>
I don't think kmscon does that, but that shouldn't be hard to implement.
<jfalempe>
I think that makes much sense for headless servers, where you usally only have fbcon currently.
<tzimmermann>
wouldn't it be better to implement drm_log in userspace entirely?
<tzimmermann>
as feature in plymouth, or something like that?
<sima>
I thought the reasons for kernel was that userspace doesn't have something running early enough
<tzimmermann>
sima, right
<sima>
but yeah if plymouth can do it and it's enough ...
<tzimmermann>
sima, if an in-kernel client can use the drm driver, so could a client in userspace
<tzimmermann>
if the userspace cannot do that, is it only a problem in the system's setup
<tzimmermann>
?
<sima>
yeah ... I think one issue was that simpledrm loads early, and plymouth only after the real drm driver because it fails to cope with the display driver change
<jfalempe>
plymouth can already display boot logs, but only after userspace is started. and it usually waits for the real driver to be loaded, so it's too late to debug early boot issues.
xroumegue has joined #dri-devel
ssmid has joined #dri-devel
ssmid has quit []
ssmid has joined #dri-devel
ssmid has quit []
ubitux has quit [Quit: WeeChat 4.3.0]
atipls has joined #dri-devel
atipls_ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
nerdopolis has joined #dri-devel
<tzimmermann>
that's a shortcoming in plymouth
<tzimmermann>
sima, that plymouth problem was related to fbdev emulation
<tzimmermann>
if plymouth opened /dev/fb, the firmware driver could not be unloaded
<tzimmermann>
but without unloading, plymouth would not close /dev/fb
<tzimmermann>
so the system stopped booting
<tzimmermann>
hence, plymouth started late
<tzimmermann>
to avoid that
<sima>
tzimmermann, hm I thought we've fixed those lifetime issues?
<sima>
at least I thought an open fbdev chardev shouldn't keep the driver/fbdev alive or stuck
<tzimmermann>
AFAIK, fbdev support has been disabled within plymouth
<tzimmermann>
sima, could be. that fbdev bug was from before simpledrm, when efifb was widely in use
<tzimmermann>
and with efifb, it would likely still happen today
<sima>
I thought you've done patches to fix up the fbdev removal?
<tzimmermann>
sima, i did what i could
<tzimmermann>
but fbdev hardware cannot be unplugged easily because of direct framebuffer-mmap that every userspace expects
<tzimmermann>
i'd not expect fbdev userspace to be able to deal with the SIGBUS that comes from writing to an unplugged framebuffer
<sima>
oh same on drm, we replace it with a dummy mapping of one page
<tzimmermann>
ah, so that would now work
<tzimmermann>
or we only do that on drm?
<tzimmermann>
but not fbdev?
bmodem has joined #dri-devel
Calandracas__ has quit [Read error: Connection reset by peer]
Calandracas has joined #dri-devel
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<sima>
tzimmermann, well not even for drm, I think only amd or maybe ttm has this implemented
<sima>
but that was the idea at least ...
<tzimmermann>
BOs in shmem and dma don't go away, so many drivers are not affected
<tzimmermann>
so this might really not be a problem in drm
<tzimmermann>
dunno about i915
guludo has joined #dri-devel
cyrozap has joined #dri-devel
cyrozap is now known as Guest2409
Guest2409 has quit []
cyrozap_ has joined #dri-devel
cyrozap_ has quit []
cyrozap_ has joined #dri-devel
feaneron has joined #dri-devel
cyrozap_ has quit []
cyrozap_ has joined #dri-devel
cyrozap_ is now known as cyrozap
cyrozap has quit []
cyrozap has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
Company has joined #dri-devel
hansg has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
leizhou has quit [Remote host closed the connection]
sukuna has joined #dri-devel
<glehmann>
alyssa: what's the issue with zink in the ddx/ddy MR?
<alyssa>
glehmann: no issue, I just didn't finish the patch because there were Too Many Bitcasts
<alyssa>
similar for gallivm, I didn't finish that one because of AoS/SoA shenanigans
<alyssa>
(the patch for e.g. bifrost was nontrivial too but I wrote that driver so I knew what to do. I haven't done much with zink or gallivm)
leizhou has joined #dri-devel
aravind has joined #dri-devel
bolson has joined #dri-devel
nerdopolis has joined #dri-devel
illwieckz has quit [Quit: I'll be back!]
illwieckz has joined #dri-devel
kzd has joined #dri-devel
<tzimmermann>
sima, jfalempe, about these in-kernel drm clients: right now each driver runs the fbdev client. i'd like to make that a generic call to instanciate a default in-kernel client. users could then select the active client in .config/cmdline. the client would be fbdev, drm_log, drm_con, whatever. this could also be controlled via sysfs, so a session manager in userspace could switch among clients. the suggested
<tzimmermann>
drm_log-to-fbdev handover could be implemented this way
<sima>
tzimmermann, if we end up with only fbdev or drm-log (and maybe not even that) we don't need that much fancy
<sima>
so I'm leaning towards figuring out how much we really need first
<sima>
instead of a lot of complexity
<tzimmermann>
it's not complex
<sima>
if every distro has their different mix, it's going to be a mess I fear
<tzimmermann>
right
<sima>
I more mean all the different clients and possibly interactions
<sima>
the cmdlin/sysfs/config selector isn't much
<tzimmermann>
but currently everything is fbcon
<tzimmermann>
i don't see much use for drm_log on typical linux distros TBH
<tzimmermann>
maybe in some embedded systems
<tzimmermann>
where a console is not wanted
<sima>
I think/hope that it's either fbcon or drm-panic+kmscon+plymouth
<jfalempe>
yes, if you don't have a keyboard connected, drm_log is enough.
<sima>
the latter would at most have a drm_client for fbdev chardev support, if anyone needs that
<jfalempe>
but for general distro, in the long run, I see drm_panic, drm_log + userspace console, as being far superior as fbcon.
<tzimmermann>
but fbdev chardev makes things complicated
<sima>
tzimmermann, just thinking ... does that even work still without config_vt?
<tzimmermann>
because how would you display it if kmscon is active
<tzimmermann>
sima, it should
<sima>
pretty sure everyone hardcodes the assumption there's a vt
<tzimmermann>
config_vt is only for fbcon
<sima>
with stuff like setting KD_GRAPHICS/TEXT
<sima>
tzimmermann, I mean the fbdev using userspace programms might freak out if there's no vt
<tzimmermann>
sima, ok. why do you think that?
<sima>
tzimmermann, fbdev chardev I think is doable, since we can switch from drm-log to fbdev client if someone opens it
<sima>
tzimmermann, well it was the case for compositors at least
<sima>
and if you run a fbdev program from the vt console, you have to set KD_GRAPHICS or fbcon will overwrite what's on screen
<sima>
so I'd expect at least some apps to blow up
<tzimmermann>
sima, i see
<sima>
maybe worth testing SDL, if that goes boom I think you can just drop fbdev chardev for config_vt=n
<tzimmermann>
but maybe let's refer these users to the old fbdev emulation
<sima>
old fbdev emulation?
<tzimmermann>
the current one with fbcon
<sima>
yeah if they just run with fbcon and config_vt=y then it's all the same
<sima>
but the underlying fbdev emulation would work without fbcon/vt
<tzimmermann>
i mean, if the system has the new drm_panic+kmscon setup, let's just drop fbdev
cmichael has joined #dri-devel
<sima>
yeah
<tzimmermann>
if someone wants fbdev, they shoul dnot run kmscon at all
<sima>
might be easier to emulate with fuse if someone really cares :-)
<jfalempe>
sima: I think the fbdev emulation can work without fbcon/vt, but it conflicts with drm_log currently.
<tzimmermann>
jfalempe, that's why i proposed to make it user-configurable
<tzimmermann>
right now, we'd have to adapt every single driver
<tzimmermann>
it would be nicer to hide everything behind a standard DRM call that inits whatever is the current default
<sima>
tzimmermann, I think we could just rename the current _fbdev_generic to _client or something like that
<sima>
since currently we only have one client
<sima>
sprinkling drm_log/con/whatever client init calls over all drivers is definitely not good
<sima>
drm-panic is different because it needs really special support, so that's unavoidable
<tzimmermann>
sima, we have a client for ttm, one for shmem, one for dma, plus several others for specific drivers
<sima>
tzimmermann, yeah but those are for buffer management differences and stuff like that
<sima>
hm ...
<sima>
so one issue with lots of in-kernel clients is that people are already annoyed about the preallocate fbdev buffer
<sima>
so more gets more annoying
<tzimmermann>
it's still distinct code with slight differences
<tzimmermann>
the good news is that they are finally all build on top of drm_client_dev
<tzimmermann>
since v6.9 or so
<jfalempe>
sima: I've also moved the client() probe to the first time we need to draw, so that when you boot with quiet, if no logs are written, the framebuffer is not allocated for drm_log.
<tzimmermann>
so we can now build an fbdev client that handles all of them; and only leave some details of buffer management to the drivers or memory managers
<sima>
jfalempe, uh ... I think we had funny cases where that means you can't allocate anymore because it's all gone
kts has joined #dri-devel
<jfalempe>
ah I see, if you need contiguous memory, and your system has too much fragmentation ?
<jfalempe>
in this case, just remove quiet from the command line ;)
<sima>
yeah, because fbcon is preallocated you can switch even when your compositor wasted everything else already
<sima>
but if it's not preallocated anymore, then switch to fbcon becomes unreliable
<sima>
which is about the only big upside of fbcon compared to kmscon
<jfalempe>
I don't think you want to switch to drm_log, it's only for boot log.
<sima>
yeah for drm_log it makes sense
<sima>
I think ..
<jfalempe>
tzimmermann: I've tested the new vga-bmc connector on a poweredge 640, and it works great. it also fix a regression introduced by "2bae076f3e352 drm/mgag200: Set .detect_ctx() and enable connector polling"
<tzimmermann>
jaflempe, thanks for testing
<jfalempe>
since this commit, BMC was showing "no video", and your series fixes it.
<tzimmermann>
jfalempe, glad to hear
<tzimmermann>
i hope this design now sticks
<jfalempe>
Yes, that's simpler and easier for userspace to handle. it's just as if we plugged another monitor for BMC.
<tzimmermann>
regular g200 is still on regular vga
<jfalempe>
I'm not sure there are still regular G200 users.
<tzimmermann>
jfalempe, i sometimes use it for testing :)
<jfalempe>
tzimmermann: oh :)
<tzimmermann>
and it's essential for free
<tzimmermann>
there's also a pcie variant of the g550. so it might be worth porting that support into the driver. the pcie card might be in use today
davispuh has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<jfalempe>
if there are users, maybe.
kts_ has joined #dri-devel
<jfalempe>
I will check aspeed BMC next, on Friday, (I will be ooo tomorrow).
<tzimmermann>
jfalempe, great! thanks a lot
alih has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts_ has quit []
hansg has joined #dri-devel
leizhou has quit [Remote host closed the connection]
mripard has quit [Quit: mripard]
leizhou has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
frieder has quit [Remote host closed the connection]
vliaskov_ has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
karolherbst_ is now known as karolherbst
aravind has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
cmichael has quit [Quit: Leaving]
epoch101 has quit []
lynxeye has quit [Quit: Leaving.]
kzd has joined #dri-devel
kts has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
leizhou has quit [Remote host closed the connection]
fab has joined #dri-devel
jsa has joined #dri-devel
guludo has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
epoch101 has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
krei-se- has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
krei-se has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
gouchi has joined #dri-devel
balrog has quit [Quit: Bye]
LeviYun has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
balrog has joined #dri-devel
leizhou has joined #dri-devel
sassefa has quit []
linusw has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
gio has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
LeviYun has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Read error: Connection reset by peer]