ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
gawin has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
fxkamd has quit []
pnowack has quit [Quit: pnowack]
ybogdano has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
co1umbarius has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
nchery has quit [Remote host closed the connection]
columbarius has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
boistordu_old has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
kts has joined #dri-devel
kts has quit []
kts has joined #dri-devel
slattann has joined #dri-devel
bgs has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
vivijim has quit [Remote host closed the connection]
camus1 has joined #dri-devel
aravind has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
kmn has joined #dri-devel
sdutt has quit [Remote host closed the connection]
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
Duke`` has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
sravn has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
sarnex_ has joined #dri-devel
sarnex has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
itoral has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
tzimmermann has joined #dri-devel
pnowack has joined #dri-devel
co1umbarius has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
columbarius has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
kts has quit []
cphealy_ has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
xantoz has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
tursulin has joined #dri-devel
rasterman has joined #dri-devel
rasterman has quit []
rasterman has joined #dri-devel
f11f13 has joined #dri-devel
f11f12 has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
<javierm>
tzimmermann: hi, did you have time to take a look to the v2 of the drm.disable_native_drivers patches? I hope that was more or less that you had in mind
<tzimmermann>
javierm, i didn't realize that there was one. is it on dri-devel?
<tzimmermann>
javierm, your comment about providing a fallback on the kernel cmdline is the main point for this AFAICT
dviola has quit [Quit: WeeChat 3.3]
<tzimmermann>
danvet, i'd appreciate your comments on this module parameter ^
<javierm>
tzimmermann: do you mean the rationale for the change is not correctly explained in the commit message of the second patch ?
<tzimmermann>
javierm, no no. i just notices that when ville asked about the reason for this change, you mentioned a fallback for recovery mode. and that's the main reason to merge it.
<javierm>
tzimmermann: ah, yes. Got it
YuGiOhJCJ has joined #dri-devel
<danvet>
tzimmermann, javierm so the idea is this is like nomodeset on steriods?
<javierm>
danvet: basically, yeah. Something for distros to let users have graphics (just using simpledrm) even if there are bugs in the platform DRM drivers
<tzimmermann>
danvet, the idea is that a driver does never release the device. so once simpledrm would take over the device and native drivers would be blocked then. distributions would set this parameter when booting into recovery mode
<tzimmermann>
it doesn't disable drm entirely, as nomodeset would
<danvet>
well how is nomodeset usually implemented?
<danvet>
either way, aside from bikesheds on naming, I'm worried that there's a few too many gaps in there
<danvet>
and with many drivers this will be very late
<danvet>
this is a parser for the radeonfb=nomodeset option
<danvet>
which is different than the stand-alone nomodeset
<javierm>
danvet: ah, I see
<tzimmermann>
oh! nomodeset enables forced text mode. so that's the connection
<danvet>
tzimmermann, yeah, but grep further and there's no user of this in vgacon.c
<tzimmermann>
just did
<danvet>
but also good chances I missed something :-)
<tzimmermann>
javierm, would you be interested in rolling out the discussed changes? it's not hard, but quite a bit of churn
<javierm>
tzimmermann: sure, I can do that
<javierm>
tzimmermann: but wasn't clear to me if you wanted to do the nomodeset cleanup and overload its semantics to disable the native drivers loading as well
mclasen has quit []
mclasen has joined #dri-devel
<tzimmermann>
here's what i'd do: add a core drm function to test (drm_check_enable(bool is_generic) ?) and roll it out in *every* probe function. then move nomodeset over into it. then add the disable-native test
<javierm>
tzimmermann: I'm not sure to agree that we should (ab)use nomodeset for this
<javierm>
unless as mentioned we add a drm.safe_mode param or something that also involves nomodeset
<tzimmermann>
javierm, we don't abuse nomodeset
<tzimmermann>
it's a separate parameter
<javierm>
tzimmermann: ahh, Ok. Sorry, I misunderstood
<tzimmermann>
the function first does the nomodeset test and then the disable-native test
<tzimmermann>
np
<javierm>
tzimmermann: Ok, I'll include that cleanup as preparatory patches of this then
<tzimmermann>
i can leave out the cleanup patch
<pq>
maybe two functions, so that native drivers don't have risk of passing drm_check_enable(true)?
<tzimmermann>
pq, TBH having just one function is much better in the long term. it's the one place to consolidate all of this.
<javierm>
tzimmermann: agreed
<pq>
tzimmermann, sure, you can have that one function behind the two public functions.
<tzimmermann>
pq, well ok
<javierm>
pq: problem is if some drivers only check one and not the other one
pcercuei has joined #dri-devel
<pq>
it's just that seeing "true" in code does not tell you anything what it's about
<tzimmermann>
i though you proposed two functions in each probe
<pq>
no
<pq>
two public functions and each driver either one or the other
<pq>
+calls
dviola has joined #dri-devel
<pq>
Something like drm_check_enabled() for native drivers, and drm_check_enabled_generic_driver() to the special case drivers that should load regardless of safe mode.
<pq>
though I wonder, does it need to be done this way in each driver, or could the generic safe-fallback drivers just not agree to release?
<tzimmermann>
pq, javierm, danvet, alternatively we could have a DRIVER_GENERIC flag in struct drm_driver.driver_features and pass the instance to the test function
<tzimmermann>
the instance might be helpful for log messages as well (e.g., driver name)
<pq>
sounds better to me
<tzimmermann>
pq, no
<javierm>
tzimmermann: that was my first approach but noticed that's a u32 and we have used most of the bits
<danvet>
tzimmermann, javierm sry was distracted
<tzimmermann>
pq, we use linux' hot-unplug to remove the driver. i don't think it has a choice
<danvet>
my point is that nomodeset _is_ the thing we're looking for
<danvet>
no need for a new parameter for this
<danvet>
because simpledrm also doesn't do any modesets
<danvet>
it's just for entirely historical and purely accidedental reasons this ended up in vgacon.c
<tzimmermann>
danvet, but what if drm is broken and we don't even want to use simpledrm?
<danvet>
and got a vgacon_ prefix
<danvet>
and somehow the function is called text_force
<danvet>
tzimmermann, if simpledrm is broken, you're busted
<danvet>
also I thought there's some modprobe syntax to tell it to not load drm.ko
<tzimmermann>
danvet, the system could still boot in real vga test mode
<tzimmermann>
text
<tzimmermann>
on the kernel commandline?
<danvet>
modprobe.blacklist=drm
<danvet>
at least according to man modprobe
<tzimmermann>
javierm, yes. the early idea might become useful now
<tzimmermann>
davnet, so we'd do module.blacklist=drm.ko to disable everything?
<javierm>
tzimmermann: you could do video=efifb
<pq>
does that work if drm.ko is built-in?
<tzimmermann>
certainly not
<pq>
or should drm.ko never be built-in?
<tzimmermann>
pq, with simpledrm drm.ko is most-likely built-in
<tzimmermann>
for early-boot graphics
<javierm>
pq: you could use initcall_blacklist=foobar
<javierm>
tzimmermann: yeah, that's what I did in the Fedora kernel config change
<pq>
do machines even have vgacon these days in any meaningful way? :-)
<danvet>
pq, yeah that's the other reason why I think including simpledrm in the nomodeset disabled drivers makes no sense
<danvet>
it might be the only thing you really have
<danvet>
definitely on arm
<tzimmermann>
danvet, javierm, pq. do we agree to introduce a single helper into drm that takes over nomodeset from vgacon? maybe this is a good start. and from there, we can easily add more parameters if we really need them
<danvet>
and everyone knows about nomodeset to help debug display issues, so I think it's worth keeping that module option as the best first step towards debugging driver load issues
<danvet>
tzimmermann, +1
<danvet>
and yeah maybe once it's in drivers/gpu/drm it'll be clearer how the code should work within drm
<pq>
and if simpledrm doesn't work, even if hw had vgacon, would vgacon really help? Wouldn't you be reaching for a different boot media or ssh already?
<tzimmermann>
javierm, may i ask you to submit a patch?
<tzimmermann>
there are still bits available in enum drm_driver_feature
<javierm>
tzimmermann: DRIVER_KMS_LEGACY_CONTEXT = BIT(31) and it's a u32
<tzimmermann>
javierm, there's plenty of space after DRIVER_SYNCOBJ_TIMELINE
<tzimmermann>
the legacy bits are at the MSB
<tzimmermann>
the rest is at the LSB
<javierm>
tzimmermann: silly me. I just looked at the last one in the enum
<tzimmermann>
:)
<javierm>
tzimmermann: but yes, I agree that's much better to make it explicit than make it implicit with the drm_aperture_remove_conflicting_framebuffers() failure
<javierm>
tzimmermann: btw, I think patch 1/2 of the v2 still has merits of its own
<javierm>
even when we are scratching that approach
<tzimmermann>
javierm, well ok. merge it then
<javierm>
tzimmermann: I don't have access drm-misc
<javierm>
tzimmermann, pq, danvet: thanks a lot for your feedback on this. I'm in a meeting but I'll re-read the discussion later and propose another patch-set
<danvet>
tzimmermann, I wonder a bit whether drm_dev_init isn't too late for a bunch of the componentized armsoc drivers
<danvet>
otoh on those we don't yet have any nomodeset support, so can't make the situation worse
<danvet>
and we can always readd epxlicit checks again or something like that
<javierm>
tzimmermann: Ok, I'll look at that too. Thanks
<tzimmermann>
danvet, what?
gawin has joined #dri-devel
<danvet>
tzimmermann, or why are we talking about DRIVER flags now again?
* danvet
maybe just confused
<tzimmermann>
danvet, a proposed idea is to add a driver flag for generic drivers and pass each driver's struct drm_driver to the new test function
<tzimmermann>
so it can ignore simpledrm and possibly others
<tzimmermann>
and we can print driver names as well
<MrCooper>
airlied: FWIW, Christian König was saying VDPAU matches AMD HW better than VA-API (which is modelled after Intel HW), so "the amd decoder fw interface seems very set on vaapi like behaviour" sounds a bit surprising
<javierm>
danvet: there's no way for the DRM core right now to differentiate between simpledrm or any other DRM driver
<javierm>
danvet: we were relying on the fact that simpledrm didn't call to drm_aperture_remove_conflicting_fbdev_framebuffers() but that's kind of a hack
<danvet>
javierm, tzimmermann won't this be a bit a chicken&egg?
<danvet>
at least for some drivers you might not have the drm_driver yet at the top of probe
<danvet>
but maybe none are this backwards
<javierm>
danvet: hmm, those are the ones using the component framework right ?
<javierm>
those then should call this helper function in their .bind callback
<gawin>
JoshuaAshton: about MR with malloc(0), you wanna keep code just for BVH?
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
frieder has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
xantoz has joined #dri-devel
JohnnyonFlame has joined #dri-devel
vivijim has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
prOMiNd has joined #dri-devel
Company has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
moa has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
prOMiNd has quit [Quit: This computer has gone to sleep]
tobiasjakobi has joined #dri-devel
<javierm>
tzimmermann, danvet: one problem with moving nomodeset handling from vgacon to drm (i.e: drivers/gpu/drm/drm_mode_config.c) is that it will only work if drm is built-in
<javierm>
because vgacon is bool but drm is tristate, so when built as a module the nomodeset param will be unknown...
<danvet>
javierm, needs a stand-alone file which is always built-in
<danvet>
as long as drm.ko is enabled
<danvet>
or something like that
<danvet>
we have a few other things like that
<daniels>
Newbyte: reliability issues
<javierm>
danvet: Ok, if a workaround like that is acceptable I can use that approach
<danvet>
javierm, that's why I suggested to stuff it into drivers/gpu/nomodeset.c or os
<javierm>
danvet: I think we should also add a drm.nomodeset regardless and deprecate the not namespaced nomodeset at some point
<danvet>
javierm, uphill struggle against ever blogpost ever
<javierm>
danvet: fair
<danvet>
not sure you can win that, and it's marginal gains at best
<danvet>
as long as we built-in only when drm is enabled I think the few bytes for that kernel option are just fine
<javierm>
danvet: nod
<danvet>
there's much bigger fish to fry for saving 100 bytes in the image (if it's that much even)
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
nchery has joined #dri-devel
nchery is now known as Guest4721
nchery has joined #dri-devel
Guest4721 has quit [Read error: Connection reset by peer]
camus1 has quit []
aswar002_ has joined #dri-devel
vivijim is now known as Guest4723
vivijim has joined #dri-devel
ramaling_ has joined #dri-devel
stuartsummers3 has joined #dri-devel
jewins1 has joined #dri-devel
pzanoni` has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Guest4723 has quit [Ping timeout: 480 seconds]
ramaling has quit [Ping timeout: 480 seconds]
stuartsummers2 has quit [Ping timeout: 480 seconds]
pzanoni has quit [Ping timeout: 480 seconds]
aswar002 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<ajax>
getting a little tired of viewperf being treated as a shadow opengl spec
<imirkin>
someone just really enjoys optimization :)
prOMiNd has joined #dri-devel
camus has joined #dri-devel
pzanoni` is now known as pzanoni
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
Duke`` has joined #dri-devel
<calebccff>
Newbyte: probably better asking in #freedreno than here?
kts has joined #dri-devel
<Newbyte>
calebccff: that's probably true, wasn't sure where to ask so this felt like a safe bet
ybogdano has joined #dri-devel
prOMiNd has quit []
pushqrdx has quit [Remote host closed the connection]
pushqrdx has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann, danvet: why most of the drivers using vgacon_text_force() also have a module "modeset" param to enable/disable modesetting ?
<danvet>
we might be able to just delete the copypasta for most of them tbh
<danvet>
for i915 and maybe the amd's there might be too much blog posts around using those
shadeslayer has joined #dri-devel
<javierm>
danvet: yes, I don't think we would be able to do it at this point. I'll add a function pointer param to the check function so drivers can also define their own check besides nomodeset
jkrzyszt has joined #dri-devel
<danvet>
javierm, uh that sounds a bit like overkill? just keep that part of the check in drivers?
<javierm>
danvet: Ok. Wanted to get rid of the duplicated code but I'm indeed over engineering this :)
<agd5f>
danvet, amdgpu doesn't support the modeset option, we just recommend modprobe.blacklist=amdgpu
<javierm>
it seems "nomodeset" is also not completely accurate since is not only disabling KMS but also DRM
<MrCooper>
javierm: the modeset module parameters were originally for disabling KMS; now that the drivers only support KMS, they're kind of redundant
<javierm>
MrCooper: I see
<MrCooper>
though another wrinkle is that amdgpu cannot be initialized by any means after booting with nomodeset on the command line
<javierm>
sorry if I'm making silly questions, it's just that I'm not super familiar with KMS/DRM
<javierm>
MrCooper: that's also true for all drivers that check for the nomodeset param AFAICT
<MrCooper>
nothing to apologize for, here be lots of dragons and hysterical raisins :)
<javierm>
:)
<MrCooper>
at least some drivers can initialize with "modprobe <driver> modeset=1" after booting with nomodeset, but not amdgpu IIRC
<MrCooper>
(I actually did that just today with qxl)
<jekstrand>
zmike: You know, you could fix the debug situation properly.....
<zmike>
jekstrand: I could, but I have other things I'm trying to rush through before I leave on holidays
<javierm>
MrCooper: Ah, you are right. Because the check is in the module_init() and not in the .probe handler
<jekstrand>
zmike: Fair.
ybogdano has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<javierm>
MrCooper: scratch that, it shouldn't matter
<MrCooper>
javierm: BTW, thanks for driving this stuff! Being able to rely on simpledrm as a fallback will be great for RHEL and GNOME in general
<zmike>
jekstrand: I'm using it locally in any case, just thought I'd put it up in case anyone else wanted to cut down cts runtimes
<zmike>
and readability
<MrCooper>
javierm: I guess it's because amdgpu doesn't have the modeset parameter
<javierm>
MrCooper: yeah, specially since mutter doesn't have an fbdev backend
<javierm>
MrCooper: oh, right
<javierm>
so the per-module modeset then now makes more sense to me, since one could override the global nomodeset
prOMiNd has joined #dri-devel
<javierm>
is not only to disable a single driver but also to force enable it
kts has quit [Quit: Konversation terminated!]
gawin has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<MrCooper>
right, though modprobe.blacklist can be used for basically the same purpose
<javierm>
MrCooper: yep, for foobar.modeset=0 but you may still need something like foobar.modeset=1 if nomodeset was used
<MrCooper>
yep, nomodeset is kind of bad that way
<javierm>
MrCooper: yeah
<MrCooper>
though making it a drm parameter which can be changed at runtime should fix that
prOMiNd has quit []
<javierm>
MrCooper: indeed
ybogdano has joined #dri-devel
shadeslayer has quit [Quit: Konversation terminated!]
shadeslayer has joined #dri-devel
hikiko has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
prOMiNd has joined #dri-devel
camus has quit []
shadeslayer has quit [Quit: Konversation terminated!]
rgallaispou has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
adjtm has quit [Read error: Connection reset by peer]
BobBeck has quit [Quit: Ping timeout (120 seconds)]
<anholt>
ah, and this adopter login path works. (member login for the new account is broken in some weird way)
<airlied>
you arent a member only an adopter
<airlied>
differwnt levels of access
<anholt>
I might expect some kind of 403 in that case, rather than a php unhandled exception :)
<anholt>
anyway, I'm in the conformance submission form now, thanks
markyacoub__ has quit []
<emersion>
Lyude: do you know if it's possible to use this to access the internal khronos discussions? https://www.x.org/wiki/Khronos/
<airlied>
no it's not
<airlied>
x.org/spi is only an adopter not a khronos member
<emersion>
rip
<emersion>
khronos could really be more open than it is
<airlied>
not really it's IP agreements that all members sign are pretty limiting
<airlied>
so it would be a major undertaking across a lot of legal departments to change it
tobiasjakobi has joined #dri-devel
<emersion>
meanwhile, a lot of people are excluded from the discussions
<emersion>
and khronos does its stuff behind closed doors
tobiasjakobi has quit [Read error: Connection reset by peer]
<airlied>
emersion: you can be nominated for individual memberships for certain working groups
<emersion>
and then get the right to pay $$$?
<emersion>
i don't see nominations mentionned anywhere
<airlied>
no it's free
<emersion>
why the heck is khronos a closed doors thing, while many other standards bodies aren't
* emersion
looks forward to creating the wayland foundation, with paid membership for wayland protocols standardization
<karolherbst>
soo.. yeah.. I think I give up on marge-bot for drm stuff
<karolherbst>
way easier to script this stuff inside dim
<airlied>
emersion: large companies with lots of lawyers started it, and they talk about things none of them want to talk about
<karolherbst>
airlied: do you think kernel upstream community is more comfortable with tagging done via scripting than some bot deciding to add some s-o-b or r-by tags?
<airlied>
the IP framework lets them talk about them without having to sue each other over patents every week
<airlied>
karolherbst: we do tagging via scripts now
<karolherbst>
mhh, true
<karolherbst>
anyway.. having a dim subcommand now which pulls trees, adds weirdo tags and repushes the tree
<karolherbst>
just need the MR id as an arg
<karolherbst>
added r-by tags from approvers today
<karolherbst>
and it doesn't have the problem like marge, which just replaces old tags
pnowack has quit [Quit: pnowack]
aswar002_ has quit []
aswar002 has joined #dri-devel
<danvet>
karolherbst, doesn't that have the downside that you still need dim around?
<danvet>
or do you think of some kind of dim bot that does that like marge
<karolherbst>
danvet: we can do the latter later, but atm maintainers will probably have dim anyway. I think having a bot is worthwhile, but marge-bot doesn't seem to really fit the bill
<karolherbst>
the gitlab ci tool + jq is quite powerful tbh.. the only thing I don't like about dim is, that it's bash :D
<karolherbst>
still contains the old patchwork links, because that's where I got the patches from
<karolherbst>
top 4 commits
<karolherbst>
it also doesn't add duplicates and stuff
jkrzyszt has quit [Ping timeout: 480 seconds]
<airlied>
jenatali: yeah it's probably a big ask for the main API competitor to sign it :-P
<jenatali>
Yeah, even though we were implementing their specs
<jenatali>
We had to schedule special out-of-IP-framework meetings to be able to talk about things. Was kinda ridiculous :)
<jenatali>
Hooray for lawyers
<karolherbst>
danvet: but yeah.. I think the gitlab <-> email bridging is something people should deal with who actually care about that :/ not sure. I think it's probably important to some degree, but...
<danvet>
karolherbst, I think if rh has the script, it would be good to shovel it a k.o folks for appeasement
<danvet>
so if you can get that released with a proper license
<airlied>
jenatali: yeah just nobody wants you contributiing back to those specs :)
ppascher has quit [Ping timeout: 480 seconds]
<airlied>
too many patents :-P
<jenatali>
Yeah
<karolherbst>
danvet: ahh.. I see
<karolherbst>
I think bentiss is the better person to talk about this though
<danvet>
oh bentiss was involved in setting this up?
<karolherbst>
not sure, I just know bentiss was more involved in the kernel ci and gitlab stuff than I was
<danvet>
I do hope k.o folks could just run the script for us and we don't have to, since I agree we shouldn't waste time or effort on it
<karolherbst>
well for now we just want it to use for internal changes.. it gets more complicated if we have to touch stuff in other trees :/
sravn has quit []
lemonzest has quit [Quit: WeeChat 3.2]
pushqrdx has joined #dri-devel
prOMiNd has joined #dri-devel
pushqrdx_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pushqrdx has quit [Remote host closed the connection]
prOMiNd has quit []
pushqrdx has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest4750
macromorgan has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
vivijim has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pushqrdx has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: mhh.. there is one problem I think we might have in regards to stable patches. So the kernel doc mentions, that all patches going into stable trees should Cc: stable, but how do we want to make that work with gitlab?
<airlied>
karolherbst: currently the submitter usually decides
<airlied>
so the tag should be there before gitlab
<karolherbst>
airlied: I meant a different problem. So at least the doc _requires_ patches to be sent to stable, but I know that at least some patches are still applied even though they only have Fixes: tags
<karolherbst>
just curious what we should do about that formal requierement
<airlied>
no we don't send the patches to stalb
<airlied>
stable
<airlied>
if you actually send patches to stable, you get a gregkh "this isn't how this works" email
<karolherbst>
okay, so as long as those fixes go through drm-misc-fixes and then drm-fixes I won't have to care about any of this, basically?
<karolherbst>
ahh...
<airlied>
pretty much
<karolherbst>
I just greped for stable, so found a note, but maybe I missinterpreted it