ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
eukara has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
elongbug has quit [Read error: Connection reset by peer]
Peste_Bubonica has quit [Quit: Leaving]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
tango_ has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
ngcortes has joined #dri-devel
ella-0_ has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
ella-0 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
flacks_ has joined #dri-devel
flacks has quit [Ping timeout: 480 seconds]
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
<zmike>
dcbaker: not sure if too early to ask, but do you have a tentative date in mind for the next branchpoint?
<dcbaker>
zmike: second Wednesday in July
camus has joined #dri-devel
* zmike
checks the calendar
<zmike>
😰
ngcortes has quit [Read error: Connection reset by peer]
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
hch12907[m] is now known as hch12907
hch12907 is now known as hch12907[m]
hch12907[m] is now known as hch12907
JohnnyonFlame has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #dri-devel
libv has joined #dri-devel
libv_ has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
srslypascal has joined #dri-devel
lemonzest has joined #dri-devel
kts has joined #dri-devel
Duke`` has joined #dri-devel
slattann has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
hikiko has joined #dri-devel
eukara has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
itoral has joined #dri-devel
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
zf has quit [Ping timeout: 480 seconds]
zf has joined #dri-devel
ppascher has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
ppascher has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
mvlad has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
jkrzyszt has joined #dri-devel
tursulin has joined #dri-devel
danvet has quit [Remote host closed the connection]
danvet has joined #dri-devel
ahajda has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
lynxeye has joined #dri-devel
marex has joined #dri-devel
marex has quit []
marex has joined #dri-devel
<tzimmermann>
airlied, danvet, i'd like to have drm-next up to date before sending the big PR for drm-misc-next. could you please forward drm-next to v5.19-rc1 ?
<danvet>
hm can do
<danvet>
tzimmermann, usually we wait with applying the first pull after -rc2, just in case -rc1 is too busted
<danvet>
but doesn't hurt to get the pull out already
<danvet>
tzimmermann, anyway it's forwarded
<tzimmermann>
danvet, i can also send without -rc1
<tzimmermann>
ok, thanks
<danvet>
tzimmermann, oh no backmerge pls
<danvet>
I thought you just need this to make sure the pr is formatted correctly
<danvet>
try to wait with backmerge for -rc2
<danvet>
if you need one
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
<danvet>
tzimmermann, at least expectation from linus is that next-up maintainer does merges and resolves conflicts
<tzimmermann>
danvet, yeah. i've been bitten by -rc1s myself :)
<danvet>
and backmerges are only if you need the upstream stuff to apply more patches
<tzimmermann>
i see. i'll send the first PR this without the backmerge.
<tzimmermann>
'this week'
rasterman has joined #dri-devel
<danvet>
tzimmermann, maybe to clarify, doing backmerges fairly often is imo good, so trees don't get out of sync too much
<danvet>
it's the "do backmerge just for the pr" which is a bit silly
<danvet>
it's the lesser form of "just rebase for pr"
<tzimmermann>
i'll backmerge after -rc2. misc-next is still at 5.18-rc5, which is a bit old already.
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
wvanhauwaert has joined #dri-devel
jimjams has quit [Quit: Connection closed for inactivity]
bmodem has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
bmodem has joined #dri-devel
pixelcluster has joined #dri-devel
rkanwal has joined #dri-devel
mclasen has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
devilhorns has joined #dri-devel
mclasen has quit []
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<tzimmermann>
jani, the mgag200 helper has been merged already. sorry. but i promise to not touch any of that code until your edid series has landed
itoral has quit [Remote host closed the connection]
<jani>
tzimmermann: thanks
alatiera0 has quit []
DPA- has joined #dri-devel
DPA has quit [Read error: Connection reset by peer]
mclasen has joined #dri-devel
alatiera0 has joined #dri-devel
alatiera0 is now known as alatiera
sdutt has joined #dri-devel
camus has quit []
sdutt has quit []
sdutt has joined #dri-devel
ogabbay_ has quit []
ogabbay has joined #dri-devel
AndrewR has quit [Ping timeout: 480 seconds]
technopoirot has quit [Ping timeout: 480 seconds]
technopo1rot has quit [Ping timeout: 480 seconds]
<javierm>
jani, tzimmermann: the i915 driver calls drm_aperture_remove_conflicting_pci_framebuffers() after devm_drm_dev_alloc()
<javierm>
this means that when doing simpledrm -> i915, the dri device will be card1
<tzimmermann>
javierm, shouldn't matter in practice
<javierm>
tzimmermann: that's what I thought, but it seems that there are some programs that assume that card0 is the "main" dri device
<javierm>
I argued with the person that reported that card0 used to be in fedora and now is card1 that is a wrong assumption and just a bug in that program
<javierm>
tzimmermann: in a way I'm happy that it changes because it breaks this kind of assumptions :)
<javierm>
but just wanted to mention in case that we wanted to move it earlier
<tzimmermann>
javierm, that program is wrong. even before simepldrm, it's not reliable
<tzimmermann>
that fact that they regularly open and close the file descriptor isn't a sign of code quality either
<javierm>
tzimmermann: yes, agreed that is a wrong assumption
<javierm>
tzimmermann: my question was mostly if we cared that it changed and if wanted to do anything about it
mclasen has quit []
<javierm>
but I'm OK if that's not an issue
<danvet>
javierm, we should be able to fix the handful of drivers that alloc the device before they kick out other framebuffers?
<danvet>
it's a bit borderline as far as regressions go
<danvet>
but also not too hard to avoid the fallout
<tzimmermann>
danvet, if we do, how does that fix the problem? if they run with multiple gpus, they could easily read from the wrong one
<javierm>
danvet: I'm torn though on whether we want to do drm_aperture_remove_conflicting_pci_framebuffers() at the end of the probe
<danvet>
tzimmermann, it fixes the problem for one gpu
<javierm>
if something fails it would be nice to keep the simpledrm dri dev
<danvet>
the example code is still garbage :-)
<tzimmermann>
danvet, their code works by chance
<danvet>
javierm, yeah but that problem is pre-existing
<javierm>
danvet: also, what happens if let's say you have a built-in LCD dri device
<javierm>
hardcoding dev nodes always seems like a bad idea to me
<danvet>
javierm, the trouble is that at least for i915 you have to kick out legacy fb _before_ you start touching hw
<danvet>
because touching hw with legacy fb still scanning out might lead to hw hangs
<danvet>
javierm, for any multi-gpu you're just screwed
<danvet>
like even display + separate render dri driver (like anything with mali gpu)
<danvet>
javierm, so this swiftshader wsi code defo gets and price for silly
<javierm>
danvet: yes, agreed to do it before touching hw. But do we want to do it before doing only sw setup (like devm_drm_dev_alloc) ?
<danvet>
but also on most x86 you really only have one gpu, and so it "works"
<javierm>
danvet: I'm not sure if the i915 driver does something wrong tbh
<danvet>
javierm, if you fail memory allocations you're very screwed at boot-up
<javierm>
danvet: fair but at least maybe you are lucky and get output in the fbcon :)
<tzimmermann>
danvet, even on x86, multi-gpu is not uncommon
<danvet>
tzimmermann, yeah
<danvet>
but there's also a strong "It worked for me" with regressions
<javierm>
danvet: anyway, happy to send a patch for i915 but I'm torn on this as mentioned
<danvet>
javierm, I think the dev_alloc is really the only thing i915 does upfront, compared to everything else after that I don't think you're really gaining anything
<danvet>
javierm, I also think a whack-a-mole approach is perfectly fine here, since on socs most systems are multi-gpu anyway and you must dynamically discover
<tzimmermann>
javierm, danvet, at least zackr has expressed interest in delaying remove-conflicting-fb stuff as late as possible
technopoirot has joined #dri-devel
<danvet>
tzimmermann, that might break pretty badly ...
<tzimmermann>
well, he could do software setup as much as possible first
<tzimmermann>
can we at least try to push back on this?
<danvet>
tzimmermann, javierm what if we would try to undo on failure?
<tzimmermann>
undo?
<javierm>
tzimmermann: I've pushed back with my fedora developer hat and it seems to have worked
<danvet>
undo the fw fbdev removal ...
<danvet>
but yeah if we get away with breaking this I'm fine too
<tzimmermann>
reregister the generic fb?
<danvet>
I mean on the fbdev side you get "wrong" numbering already anyway
<danvet>
tzimmermann, yeah
<danvet>
maybe too stupid an idea
kts has joined #dri-devel
<danvet>
tzimmermann, javierm alternative might be to delay registering the idr
<tzimmermann>
that would only work until driver touch hardware
<danvet>
but that means drm_dev_register could then fail, which is annoying
<danvet>
tzimmermann, ah yeah right
<danvet>
tbh I really don't feel like bending over backwards for driver load fail
<javierm>
sorry for bringing a controversial topic :)
<danvet>
javierm, I'm happy, distracts from a meeting I'm hanging in :-)
<javierm>
:D
<tzimmermann>
:D
technopo1rot has joined #dri-devel
<tzimmermann>
i think we should push back on this until linus gets pissed. then we can still update i915 :)
<javierm>
tzimmermann: sounds like a plan to me
<danvet>
ack
technopo2rot has joined #dri-devel
Ntemis has joined #dri-devel
Ntemis has quit [Read error: Connection reset by peer]
<danvet>
javierm, I guess we should move this entire mess up into driver model
<danvet>
somehow
<danvet>
or at least make sure it's pretty clean first
<javierm>
danvet: yes, that was the outcome of the last time we discussed this
eukara has quit [Remote host closed the connection]
<javierm>
making it in 2 steps, 1) unify fbdev and drm aperture list and device removal and 2) move it to the linux driver model
eukara has joined #dri-devel
<javierm>
that's what I need to document as items in todo.rst
<javierm>
danvet: I understand the goal of those patches but I believe it will lead to more problems down the road
rgallaispou has joined #dri-devel
rgallaispou has quit []
<danvet>
javierm, yeah leaking all the internal horrors isn't great :-/
rgallaispou has joined #dri-devel
<javierm>
also, why they are using user-space drivers for this ?
<danvet>
javierm, I think if we can first move everything over to sysfb and vfio just uses sysfb, we should be in pretty good shape instead?
<javierm>
danvet: isn't sysfb just a filesystem representation of the linux device model anyways ?
<danvet>
javierm, I mean the code in drivers/firmware/sysfb.c
<javierm>
danvet: oh, sorry. I'm blind. Read that as "sysfs" instead sysfb
<javierm>
tab completion in my head is broken
<danvet>
javierm, oh your new sysfb stuff hasn't landed yet?
<danvet>
or do I look in the wrong place in drm-misc-next?
<javierm>
danvet: no, a lot of bikeshedding happened and then was decided that it was just adding more hacks on top of the current hacks and we should fix it properly
<javierm>
hence my comment about posting patches for todo.rst
<danvet>
javierm, oh I missed that conclusion, I thought moving a few more things towards sysfb.c looked like the right step
<javierm>
danvet: I could revive that patch-set if you prefer to go that way, but tzimmermann pushed back
* danvet
shrugs
<danvet>
I'm just worried that if we want to do this in one huge leap it wont happen
<danvet>
so small steps with some more hacks sounds useful
<danvet>
plus vfio now also looking into this gives another reason for sysfb_disable
<danvet>
so frankly I'd land that and ask sysfb to rebase on top
<danvet>
and then we land the sysfb_disable in vfio through drm-misc or so
<javierm>
danvet: I certainly don't think that will have the bandwidth to fix it properly tbh
<danvet>
javierm, then I kinda don't get why we shouldn't merge the sysfb_disable stuff
<javierm>
danvet: let's wait for tzimmermann to chime in. But I also think that it improves the current state
<danvet>
javierm, hm vfio can't just reuse the sysfb stuff, since it doesn't maintain the aperture list
<jekstrand>
emersion, danvet: I"m starting to want a way to create a dma-buf without a driver. :-/
<danvet>
jekstrand, that sounds like android's dma-buf heaps
<jekstrand>
robclark: Ok. Yeah, maybe not. But then why does qualcom have a rotation extension for Vulkan?!? Why would they do that to themselves?
<jekstrand>
danvet: Yeah, maybe.
<danvet>
jekstrand, so what do you need this for
<jekstrand>
danvet: Testing dma-buf ioctls. 😂
<danvet>
uh
<javierm>
danvet: but does really need it? Or they just want to remove the devices for generic drivers to use a user-space one ?
<danvet>
javierm, from the kernel pov, vfio-pci is the driver
<danvet>
it's just that qemu runs in userspace
<danvet>
so things get funny
<javierm>
danvet: ah, I see. But my point stands, would unregistering "simple-framebuffer" device be enough ?
<javierm>
or "efi-framebuffer" ?
<javierm>
they don't really care about the aperture list, unless they want to remove a real DRM driver that uses the same PCI BARs
<robclark>
jekstrand: "pre-rotation" for android, to avoid extra blit for screen rotation, probably.. they have a similar hack feature in their gl blob.. there was a not-quite-complete MR to implement a similar thing in mesa
<javierm>
danvet: in other words, they are just using the aperture list as a mean to an end
mclasen has joined #dri-devel
<javierm>
danvet: and sysfb_disable() triggers a device unregistering
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Duke`` has joined #dri-devel
bmodem has joined #dri-devel
<macc24>
so i'm adding a panel orientation quirk for an x86 handheld
<macc24>
it has 3 different versions, all of them have a batch with product name prefixed by vendor name
<macc24>
should i add 6 matches or use DMI_MATCH instead of DMI_EXACT_MATCH, even if it would match for a future version of that device?
<mlankhorst>
doubt it's gonna be fixed
pixelcluster has quit [Ping timeout: 480 seconds]
<macc24>
mlankhorst: huh?
<mlankhorst>
I'd just match future versions, tbh
<macc24>
so i should have just one entry with `DMI_MATCH(DMI_BOARD_NAME, "foobar")` instead of 6 exact ones?
<macc24>
btw those 3 versions of device are differing only in name and ram/ssd capacity
<mlankhorst>
What is the exact string?
<macc24>
for product names: 'NEXT', 'NEXTPro', 'NEXTADVANCE', in a batch or two of those devices it's prefixed by 'AYANEO
<macc24>
the board vendor name is always 'AYANEO'
<mlankhorst>
I guess exact match, just in case
<macc24>
err, s/product names/board names/
<macc24>
okay
<jani>
note that plain DMI_MATCH leads to strstr()
<jani>
i.e. the string may be anywhere
<jani>
DMI_EXACT_MATCH is strcmp() on the full string
<macc24>
i'm mainly worried about them releasing a 'NEXT 2' with screen rotated differently
<macc24>
which would be a problem if all is checked is 'NEXT' *anywhere*
jimjams has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
<macc24>
i'll push to mailing list once i get confirmation that it works fine on 5 versions of the device that i don't have... might take a while
alyssa has joined #dri-devel
<alyssa>
is there a shader info property for # of push constants?
<alyssa>
I don't see one
frieder has quit [Remote host closed the connection]
neonking has joined #dri-devel
mbrost has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
wv_ has joined #dri-devel
idr has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
wvanhauwaert has quit [Ping timeout: 480 seconds]
wvanhauwaert has joined #dri-devel
wvanhauwaert has quit []
wv_ has quit []
wvanhauwaert has joined #dri-devel
iive has joined #dri-devel
yoslin has quit [Quit: WeeChat 3.5]
yoslin has joined #dri-devel
mbrost_ has joined #dri-devel
stuart has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
pixelcluster has joined #dri-devel
mbrost__ has joined #dri-devel
<anarsoul>
I have a question regarding gallium pipe_context.set_framebuffer_state() -- what backend driver is supposed to do if all the cbufs are NULL and zsbuf is NULL?
mattrope_ has quit []
mattrope has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
<zmike>
it's a no attachment framebuffer
<zmike>
so you just discard everything
<zmike>
can do it at the hw level or with dummy buffers
<javierm>
danvet: that is, if they want to use vfio-io for qemu pass-through, they will have a problem with any PCI device that has a driver bound for that device
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
dreda has joined #dri-devel
<javierm>
danvet: so maybe they need something that's more generic to unregister PCI devices that they want to bind to vfio-pci or something like that
marex has quit [Ping timeout: 480 seconds]
<zmike>
is something going on with git today? fetches seem oddly slow
Akari has quit [Read error: Connection reset by peer]
<jenatali>
Yeah, I'm lighting up SSE4.1 on Windows
<jenatali>
I dunno why it doesn't trip up on the Linux builds for Lavapipe though
<zmike>
probably common_x86.c has some windows guards or something
<jenatali>
Nope, it builds fine on Windows
<jenatali>
It's only linking lavapipe that fails
<zmike>
sure, it builds fine, but it's missing that symbol
<jenatali>
No, it has the symbol
<zmike>
huh
<jenatali>
'Cause llvmpipe would fail too if it didn't
mbrost__ has joined #dri-devel
<jenatali>
Now why don't I have lavapipe in my local build... let's see if I can just flip it on
<zmike>
jenatali: ah probably because that file is in src/mesa
<zmike>
but then used in util
<jenatali>
Right, part of libmesa
<zmike>
I think lavapipe doesn't include all of mesa
<zmike>
this should probably be fixed...
<jenatali>
Why does it successfully link on Linux? That's weird
<jenatali>
zmike: Need an issue on it?
<zmike>
yeah this might need dcbaker to figure out
srslypascal is now known as Guest1425
srslypascal has joined #dri-devel
Guest1425 has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
<jenatali>
Hm looks like I didn't actually flip on SSE4.1 support anyway with that change because the cpuid detection is all #ifdef'd out with other stuff that's disabled
<jenatali>
So it'll compile it in but won't actually run any of it lol
<jenatali>
system_has_kms_drm is a very odd condition to use for guarding asm usage...
mbrost_ has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
mbrost__ has quit [Remote host closed the connection]
* danvet
apologizes for stirring up dead bodies :-/
<danvet>
javierm, for pci unbinding you can just unbind the driver for that pci device
<tzimmermann>
danvet, np
<javierm>
tzimmermann: sorry :)
<javierm>
tzimmermann, danvet: I can post a v6 and we discuss there ?
<danvet>
javierm, so that doesn't need new infra
alyssa has left #dri-devel [#dri-devel]
<danvet>
it's the platform/fw devices, which I think is a uniquely display driver situation
<danvet>
maybe with the exception of stuff like legacy ps2 emulation on top of usb
<javierm>
danvet: yes, I know. My point was that they can already do that (and same for the platform/fw devices, just need special case)
<danvet>
javierm, well the issue is the same as we have, the fw/plat device is totally disconnected from the real device
mbrost__ has joined #dri-devel
<danvet>
whether pci or platform
<javierm>
danvet: yeah. If that's the case then I think they could just use sysfb_disable() and let sysfb unregister the device
<javierm>
that will trigger the driver removal path too
<javierm>
and they could happily pass-through from qemu
<tzimmermann>
javierm, danvet, i pushed back on the current patches because they had all the back and forth between modules and no clear structure. (it was more a gut feeling.) i finally realized that we're trying to solve this at the wrong level. we're tracking drm and fbdev devices and then unplug the underlying platofrm devices as needed. what we really should track are the generic platform devices and the resources they claim
srslypascal has joined #dri-devel
<javierm>
tzimmermann: yes, and I agree with you on that. But danvet think that is still a step in the right direction
<javierm>
tzimmermann, danvet: btw, I simplified the series again and dropped the most complex patch
<danvet>
javierm, tzimmermann well looking at the vfio patch I'm not sure sysfb really gives that much more structure
<danvet>
since the matching between real dev and fw dev is missing
<javierm>
danvet: well, they can drop all fw dev
<danvet>
so maybe we should indeed lift that first into sysfb
<danvet>
also they have a check for vga class
<danvet>
which I'm not sure we should leak into vfio
<tzimmermann>
my proposed plan was roughtly: 1) move drm aperture helpers next to sysfb. 2) re-implement fbdev on top of it. 3) whenever we create a platform device for a generic framebuffer track the resources at the sysfb level *before* we eaven reach drm/fbdev
<danvet>
like for vfio I think the interface should be "nuke everything for this struct device *"
<danvet>
tzimmermann, hm yeah maybe
<danvet>
otoh I'm not sure whether the aperture helpers are really the right thing
<danvet>
but maybe they are
<danvet>
tzimmermann, maybe step 0) convert all firmware fbdev drivers over to sysfb
<danvet>
is required first
<tzimmermann>
danvet, in an ideal world, all devices and drivers would track their struct resources correctly. but well...
<danvet>
so that we don't have to maintain the list of apertures anymore like fbdev does
<danvet>
but just have to do a match for the single one that matters?
<tzimmermann>
davnet, step 0) is almost done
<danvet>
tzimmermann, yeah just wanted to make sure we agree on that
<tzimmermann>
there's vga16 and ofdrm
<danvet>
since you didn't include it, and if we have to move the fbdev device list into sysfb I think it's back to "too ugly a hack" territory
<tzimmermann>
the others are handled via sysfb
<javierm>
danvet: I already have a v6 that just tested, let me post that anyways
<javierm>
I think the patches are too simply now to not just push it
<javierm>
*simple
<javierm>
regardless of the vfio-pci situation
<tzimmermann>
danvet and we also create generic framebuffers from device tree (of display and simple-framebuffer nodes). we need to register them at the apertures as well
mbrost__ has quit [Remote host closed the connection]
mbrost__ has joined #dri-devel
<javierm>
tzimmermann: please take a look at v6. Before remove conflicting framebuffers, sysfb_disable() is called and that unregister its own registered device
<javierm>
then the device removal loop won't have any sysfb device in registered_fb anymore
<javierm>
both things seems the correct thing to do, no matter how we solve this properly
<javierm>
and that allows to rever the {efi,simple}fb hack that checks for num_registered_fb and makes that internal to fbdev core
<tzimmermann>
javierm, i haven't looked at v6 yet. but from earlier revisions, i think something like sysfb_disable() is part of the problem. the tracking information is already in the calls to acquire and remove frambuffer ranges. we should not disable sysfb explictly. so if we land these patches now, i suspect that we're going to basically revert them as soon as we try to address the problem in a more consistent way
<tzimmermann>
to be clear, i don't want to be the roadblock here. i'll take a look at the patches and if you all think they shoudl land, then do so.
<javierm>
tzimmermann: yes, I agree that a more general solution is needed but as mentioned I think these are small changes that solve at least part of the issues
<tzimmermann>
i just have this impression that it's not a step towards actually solving the existing issues
<javierm>
tzimmermann: well, it solves the race and allow to revert even more uglier hacks in fbdev drivers
<javierm>
and also stop the bleeding by making some variables private to fbdev to prevent drivers from using it
<tzimmermann>
javierm, i'll take a look at the new patchset tomorrow. start nagging me if you haven't heard anything by friday :)
<javierm>
tzimmermann: thanks :) I'm also happy to bury this dead body again
<javierm>
but as mentioned to danvet at least I don't think that will have time to work on a more general solution in the short term
technopoirot has quit [Ping timeout: 480 seconds]
<danvet>
javierm, maybe we need to volunteer the vfio guys to make that happen?
* danvet
going for "evil maintainer mode"
<javierm>
danvet :D
<javierm>
tzimmermann, danvet: we could also land this and I can post a todo item as a follow-up
<javierm>
leaving for today folks, thanks again for all your help
<tzimmermann>
c u
simon-perretta-img_ has joined #dri-devel
neonking_ has joined #dri-devel
jeeeun841 has joined #dri-devel
kchibisov_ has joined #dri-devel
vyivel_ has joined #dri-devel
ifreund_ has joined #dri-devel
sumoon has joined #dri-devel
FLHerne_ has joined #dri-devel
larunbe has joined #dri-devel
dos1 has joined #dri-devel
sigmaris has joined #dri-devel
LaserEyess_ has joined #dri-devel
jani_ has joined #dri-devel
milek7_ has joined #dri-devel
Lucretia-backup has joined #dri-devel
pjakobsson_ has joined #dri-devel
mmind00_ has joined #dri-devel
Arsen_ has joined #dri-devel
pinchart1 has joined #dri-devel
dreda_ has joined #dri-devel
gio_ has joined #dri-devel
Lynne has joined #dri-devel
sravn_ has joined #dri-devel
loki_val has joined #dri-devel
Haaninjo has joined #dri-devel
dreda has quit [reticulum.oftc.net helix.oftc.net]
rasterman has quit [reticulum.oftc.net helix.oftc.net]
ppascher has quit [reticulum.oftc.net helix.oftc.net]
bbrezillon has quit [reticulum.oftc.net helix.oftc.net]
i-garrison has quit [reticulum.oftc.net helix.oftc.net]
unevenrhombus[m] has quit [reticulum.oftc.net helix.oftc.net]
simon-perretta-img has quit [reticulum.oftc.net helix.oftc.net]
jeeeun84 has quit [reticulum.oftc.net helix.oftc.net]
Terman has quit [reticulum.oftc.net helix.oftc.net]
jani has quit [reticulum.oftc.net helix.oftc.net]
crabbedhaloablut has quit [reticulum.oftc.net helix.oftc.net]
neonking has quit [reticulum.oftc.net helix.oftc.net]
pjakobsson has quit [reticulum.oftc.net helix.oftc.net]
Lucretia has quit [reticulum.oftc.net helix.oftc.net]
sravn has quit [reticulum.oftc.net helix.oftc.net]
kchibisov has quit [reticulum.oftc.net helix.oftc.net]
pinchart1 has left #dri-devel [#dri-devel]
sumoon_ has quit [reticulum.oftc.net helix.oftc.net]
ifreund has quit [reticulum.oftc.net helix.oftc.net]
vyivel has quit [reticulum.oftc.net helix.oftc.net]
urja has quit [reticulum.oftc.net helix.oftc.net]
jannau has quit [reticulum.oftc.net helix.oftc.net]
Lynne_ has quit [reticulum.oftc.net helix.oftc.net]
dos11 has quit [reticulum.oftc.net helix.oftc.net]
sigmaris_ has quit [reticulum.oftc.net helix.oftc.net]
dv_ has quit [reticulum.oftc.net helix.oftc.net]
LaserEyess has quit [reticulum.oftc.net helix.oftc.net]
unrelentingtech has quit [reticulum.oftc.net helix.oftc.net]
znullptr[m] has quit [reticulum.oftc.net helix.oftc.net]
chivay has quit [reticulum.oftc.net helix.oftc.net]
JosExpsito[m] has quit [reticulum.oftc.net helix.oftc.net]
gnustomp[m] has quit [reticulum.oftc.net helix.oftc.net]
kusma has quit [reticulum.oftc.net helix.oftc.net]
colemickens has quit [reticulum.oftc.net helix.oftc.net]
exit70[m] has quit [reticulum.oftc.net helix.oftc.net]
Sumera[m] has quit [reticulum.oftc.net helix.oftc.net]
cmeissl[m] has quit [reticulum.oftc.net helix.oftc.net]
imre has quit [reticulum.oftc.net helix.oftc.net]
RAOF has quit [reticulum.oftc.net helix.oftc.net]
martijnbraam has quit [reticulum.oftc.net helix.oftc.net]
Eighth_Doctor has quit [reticulum.oftc.net helix.oftc.net]
nielsdg has quit [reticulum.oftc.net helix.oftc.net]
bluepenquin has quit [reticulum.oftc.net helix.oftc.net]
tintou has quit [reticulum.oftc.net helix.oftc.net]
Newbyte has quit [reticulum.oftc.net helix.oftc.net]
Strit[m] has quit [reticulum.oftc.net helix.oftc.net]
mighty17 has quit [reticulum.oftc.net helix.oftc.net]
zzoon_holidays_till_8th[m] has quit [reticulum.oftc.net helix.oftc.net]
mmind00 has quit [reticulum.oftc.net helix.oftc.net]
gio has quit [reticulum.oftc.net helix.oftc.net]
zamundaaa has quit [reticulum.oftc.net helix.oftc.net]
emersion has quit [reticulum.oftc.net helix.oftc.net]
milek7 has quit [reticulum.oftc.net helix.oftc.net]
FLHerne has quit [reticulum.oftc.net helix.oftc.net]
alarumbe has quit [reticulum.oftc.net helix.oftc.net]
Arsen has quit [reticulum.oftc.net helix.oftc.net]
aissen has quit [reticulum.oftc.net helix.oftc.net]
cyrozap has quit [reticulum.oftc.net helix.oftc.net]
pinchartl has quit [reticulum.oftc.net helix.oftc.net]
pinchartl has joined #dri-devel
emersion has joined #dri-devel
jani_ has quit []
Arsen_ has quit []
jani has joined #dri-devel
jani is now known as Guest1489
LaserEyess_ has quit []
i-garrison has joined #dri-devel
ppascher has joined #dri-devel
Arsen has joined #dri-devel
Terman_ has joined #dri-devel
imre_ has joined #dri-devel
rasterman has joined #dri-devel
bbrezillon has joined #dri-devel
unevenrhombus[m] has joined #dri-devel
dv_ has joined #dri-devel
cmeissl[m] has joined #dri-devel
urja has joined #dri-devel
RAOF has joined #dri-devel
exit70[m] has joined #dri-devel
martijnbraam has joined #dri-devel
bluepenquin has joined #dri-devel
Eighth_Doctor has joined #dri-devel
tintou has joined #dri-devel
zzoon_holidays_till_8th[m] has joined #dri-devel
aissen has joined #dri-devel
cyrozap has joined #dri-devel
Strit[m] has joined #dri-devel
LaserEyess has joined #dri-devel
jannau_ has joined #dri-devel
Guest1489 is now known as jani
jannau_ has quit []
mbrost_ has joined #dri-devel
zamundaaa has joined #dri-devel
jannau has joined #dri-devel
<anarsoul>
anholt: have you looked into spec@!opengl 1.1@depthstencil-default_fb-drawpixels-float-and-ushort* flakes on v3d and vc4?
gnustomp[m] has joined #dri-devel
<anholt>
certainly not in years
<anarsoul>
they're also flake on lima, so I suspect it's a bug in u_transfer_helper
slattann has quit []
JosExpsito[m] has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
znullptr[m] has joined #dri-devel
<anarsoul>
robclark: same question for freedreeno :)
<anarsoul>
spec@!opengl 1.1@depthstencil-default_fb-drawpixels-* is in failures list for a530
mbrost_ has quit [Ping timeout: 480 seconds]
ifreund_ is now known as ifreund
Sumera[m] has joined #dri-devel
<Lyude>
ugh, MAINTAINERs appears to be broken and just broke git send-email for me, but I can't see a single one of the patches that would have been sent in my Sent box. Did anyone see any of the MST patches I just sent onto dri-devel?
<javierm>
Lyude: I got "[RFC 03/18] drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation"
<javierm>
and all the others made it to dri-devel AFAICT
<Lyude>
gotcha, I will resend in a bit with the RESEND prefix added then. need to figure out why git send-email is exploding before I do that
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<Lyude>
oh man i forgot how absurdly illegible perl is
pnowack has joined #dri-devel
mbrost_ has joined #dri-devel
jagan_ has joined #dri-devel
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
chivay has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
<javierm>
Lyude: btw, git-send-email --dry-run is useful for these cases
<Lyude>
javierm: will keep in mind
<Lyude>
it semes it's the () in the MAINTAINERS entries for i915 and gma500 messing things up, the script ends up outputting the start ( in the project name but not the ending one
<javierm>
sigh
<Lyude>
yeah, I wanted to see if I could find the issue in ./scripts/get_maintainer.pl but. boy oh boy I forgot how painful perl is
larunbe is now known as alarumbe
mvlad has quit [Remote host closed the connection]
technopoirot has joined #dri-devel
nielsdg has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Thymo has joined #dri-devel
<jekstrand>
airlied: Ok, so gregkh is pretty determined to not allow us to pull any stunts when it comes to dma-buf sync_file import/export.
<jekstrand>
In Mesa, we can handle that reasonably well. I just drop the fixup patch at the end of my WSI MR. That, or I make the up-front check take advantage of the driver somehow. (There are a number of ways; they all kinda suck)
<jekstrand>
This really isn't hard for the driver to detect. That's the sad part. It's really only a giant pain for misc. userspace that doesn't want to have to open random render nodes with gbm.
<jekstrand>
Though emersion said he was ok with opening random render nodes. Not sure if he's ok with opening them via gbm.
mbrost__ has joined #dri-devel
<jekstrand>
It's annoying how much of a driver you have to spin up for that, but it'd work.
<bnieuwenhuizen>
spinning up a basic vulkan instance is pretty easy though?
<jekstrand>
Yeah
<jekstrand>
Neither are hard
<jekstrand>
With GBM, you're guaranteed to not end up on LLVMpipe, though.
<jekstrand>
I think
<jekstrand>
You can ensure you're actually talking to /dev/renderD128
<bnieuwenhuizen>
you have a nice vulkan extension for that too IIRC
unrelentingtech has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
<airlied>
jekstrand: I think just sticking a CAP on the drm render node is the best worst option
colemickens has joined #dri-devel
kusma has joined #dri-devel
pcercuei has quit [Quit: dodo]
Daanct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
adavy has quit [Ping timeout: 480 seconds]
<jekstrand>
airlied: Yeah....
tzimmermann_ has joined #dri-devel
iive has quit []
tzimmermann has quit [Ping timeout: 480 seconds]
mbrost__ has quit [Remote host closed the connection]
<airlied>
bnieuwenhuizen: you remember why we can create cmd buffer with NULL pool?
* airlied
is pretty sure it's illegal from the API pov, but there might be something internall
<airlied>
actually looks like radv doesn't do that anymore, tu must have c-p older copy :-P
Akari has quit [Read error: Connection reset by peer]
karolherbst has quit [Read error: Connection reset by peer]