09:06 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
09:07 tzimmermann: javierm, i didn't realize that there was one. is it on dri-devel?
09:09 tzimmermann: javierm, found it
09:09 javierm: tzimmermann: yes, https://lkml.org/lkml/2021/10/25/168. The ping was worth it then :)
09:09 javierm: tzimmermann: cool, thanks
09:14 tzimmermann: javierm, your comment about providing a fallback on the kernel cmdline is the main point for this AFAICT
09:16 tzimmermann: danvet, i'd appreciate your comments on this module parameter ^
09:19 javierm: tzimmermann: do you mean the rationale for the change is not correctly explained in the commit message of the second patch ?
09:20 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.
09:20 javierm: tzimmermann: ah, yes. Got it
09:23 danvet: tzimmermann, javierm so the idea is this is like nomodeset on steriods?
09:25 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
09:25 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
09:26 tzimmermann: it doesn't disable drm entirely, as nomodeset would
09:27 danvet: well how is nomodeset usually implemented?
09:28 danvet: either way, aside from bikesheds on naming, I'm worried that there's a few too many gaps in there
09:28 danvet: and with many drivers this will be very late
09:28 danvet: https://paste.debian.net/1217750/ <- so maybe something like this on top as additional catch?
09:29 danvet: maybe also ask gregkh for how to best do this
09:30 tzimmermann: danvet, nomodeset is in vgacon AFAICS. is that available on platforms without vga?
09:30 danvet: tzimmermann, we could fix that
09:30 danvet: I'm kinda torn between not overloading nomodeset
09:31 danvet: but also nomodeset is what everyone uses
09:31 tzimmermann: danvet, anything in drm_dev_init() is too late
09:31 tzimmermann: the first thing native drivers to to kickout the generic driver. we'd need a test there
09:32 tzimmermann: so we could introduce a separate test or use existing aperture helpers
09:32 danvet: well we also have all the various vgacon_text_force checks sprinkled all over
09:32 danvet: I think it would be nice to unify those while we do this stuff?
09:32 danvet: also since vgacon_text_force is a per-driver thing we could just reinterpret it as "prevent anything except simpledrm from loading"
09:32 javierm: danvet: something like drm.safe_mode ?
09:33 danvet: tzimmermann, we can also move the nomodeset parameter into drivers/gpu/nomodeset.c, out from vgacon.c
09:33 tzimmermann: danvet, i've seen vgacon_text_force. always looked like a hack to me
09:34 danvet: tzimmermann, it's just a strange function name
09:34 danvet: really it's "is nomodeset set?" check
09:34 javierm: danvet: I think that's a desireable thing to do regardless, nodmoset not having a drm namespace is not nice
09:34 danvet: just accidentally ended up in vgacon.c
09:34 tzimmermann: danvet, ideally we'd have a single helper to sort this out. and it would be the first call in *every* probe function
09:34 tzimmermann: could we roll-out that?
09:35 danvet: tzimmermann, coffee maybe not kicked in, but a few quick git grep says that all users of nomodeset are in drivers/gpu
09:35 danvet: and it has nothing to do with vgacon at all
09:35 danvet: tzimmermann, yeah I think that'd be best
09:36 javierm: danvet: drivers/video/fbdev/aty/radeon_base.c uses it too
09:36 javierm: but could be split in fb.nomodeset and drm.nomodeset
09:36 tzimmermann: danvet, i grepped nomodeset and it turned up https://elixir.bootlin.com/linux/latest/source/drivers/video/console/vgacon.c#L122
09:36 danvet: javierm, nope
09:36 danvet: this is a parser for the radeonfb=nomodeset option
09:36 danvet: which is different than the stand-alone nomodeset
09:37 javierm: danvet: ah, I see
09:38 tzimmermann: oh! nomodeset enables forced text mode. so that's the connection
09:38 danvet: tzimmermann, yeah, but grep further and there's no user of this in vgacon.c
09:38 tzimmermann: just did
09:38 danvet: but also good chances I missed something :-)
09:39 tzimmermann: javierm, would you be interested in rolling out the discussed changes? it's not hard, but quite a bit of churn
09:43 javierm: tzimmermann: sure, I can do that
09:43 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
09:46 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
09:46 javierm: tzimmermann: I'm not sure to agree that we should (ab)use nomodeset for this
09:47 javierm: unless as mentioned we add a drm.safe_mode param or something that also involves nomodeset
09:47 tzimmermann: javierm, we don't abuse nomodeset
09:47 tzimmermann: it's a separate parameter
09:47 javierm: tzimmermann: ahh, Ok. Sorry, I misunderstood
09:47 tzimmermann: the function first does the nomodeset test and then the disable-native test
09:47 tzimmermann: np
09:47 javierm: tzimmermann: Ok, I'll include that cleanup as preparatory patches of this then
09:48 tzimmermann: i can leave out the cleanup patch
09:49 pq: maybe two functions, so that native drivers don't have risk of passing drm_check_enable(true)?
09:49 tzimmermann: pq, TBH having just one function is much better in the long term. it's the one place to consolidate all of this.
09:50 javierm: tzimmermann: agreed
09:50 pq: tzimmermann, sure, you can have that one function behind the two public functions.
09:50 tzimmermann: pq, well ok
09:50 javierm: pq: problem is if some drivers only check one and not the other one
09:51 pq: it's just that seeing "true" in code does not tell you anything what it's about
09:51 tzimmermann: i though you proposed two functions in each probe
09:51 pq: no
09:51 pq: two public functions and each driver either one or the other
09:51 pq: +calls
09:53 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.
09:54 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?
09:54 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
09:55 tzimmermann: the instance might be helpful for log messages as well (e.g., driver name)
09:55 pq: sounds better to me
09:55 tzimmermann: pq, no
09:55 javierm: tzimmermann: that was my first approach but noticed that's a u32 and we have used most of the bits
09:55 danvet: tzimmermann, javierm sry was distracted
09:56 tzimmermann: pq, we use linux' hot-unplug to remove the driver. i don't think it has a choice
09:56 danvet: my point is that nomodeset _is_ the thing we're looking for
09:56 danvet: no need for a new parameter for this
09:56 danvet: because simpledrm also doesn't do any modesets
09:56 danvet: it's just for entirely historical and purely accidedental reasons this ended up in vgacon.c
09:56 tzimmermann: danvet, but what if drm is broken and we don't even want to use simpledrm?
09:56 danvet: and got a vgacon_ prefix
09:56 danvet: and somehow the function is called text_force
09:57 danvet: tzimmermann, if simpledrm is broken, you're busted
09:57 danvet: also I thought there's some modprobe syntax to tell it to not load drm.ko
09:57 tzimmermann: danvet, the system could still boot in real vga test mode
09:57 tzimmermann: text
09:57 tzimmermann: on the kernel commandline?
09:58 danvet: modprobe.blacklist=drm
09:58 danvet: at least according to man modprobe
09:58 tzimmermann: javierm, yes. the early idea might become useful now
09:59 tzimmermann: davnet, so we'd do module.blacklist=drm.ko to disable everything?
10:00 javierm: tzimmermann: you could do video=efifb
10:00 pq: does that work if drm.ko is built-in?
10:00 tzimmermann: certainly not
10:00 pq: or should drm.ko never be built-in?
10:01 tzimmermann: pq, with simpledrm drm.ko is most-likely built-in
10:01 tzimmermann: for early-boot graphics
10:01 javierm: pq: you could use initcall_blacklist=foobar
10:01 javierm: tzimmermann: yeah, that's what I did in the Fedora kernel config change
10:01 pq: do machines even have vgacon these days in any meaningful way? :-)
10:03 danvet: pq, yeah that's the other reason why I think including simpledrm in the nomodeset disabled drivers makes no sense
10:03 danvet: it might be the only thing you really have
10:03 danvet: definitely on arm
10:03 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
10:04 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
10:04 danvet: tzimmermann, +1
10:04 danvet: and yeah maybe once it's in drivers/gpu/drm it'll be clearer how the code should work within drm
10:05 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?
10:07 tzimmermann: javierm, may i ask you to submit a patch?
10:07 tzimmermann: there are still bits available in enum drm_driver_feature
10:08 javierm: tzimmermann: DRIVER_KMS_LEGACY_CONTEXT = BIT(31) and it's a u32
10:09 tzimmermann: javierm, there's plenty of space after DRIVER_SYNCOBJ_TIMELINE
10:09 tzimmermann: the legacy bits are at the MSB
10:09 tzimmermann: the rest is at the LSB
10:09 javierm: tzimmermann: silly me. I just looked at the last one in the enum
10:09 tzimmermann: :)
10:11 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
10:11 javierm: tzimmermann: btw, I think patch 1/2 of the v2 still has merits of its own
10:11 javierm: even when we are scratching that approach
10:12 tzimmermann: javierm, well ok. merge it then
10:14 javierm: tzimmermann: I don't have access drm-misc
10:14 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
10:15 tzimmermann: javierm, i guess you should get commit rights then: https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html
10:15 danvet: yeah probably time for that too
10:15 danvet: tzimmermann, I wonder a bit whether drm_dev_init isn't too late for a bunch of the componentized armsoc drivers
10:16 danvet: otoh on those we don't yet have any nomodeset support, so can't make the situation worse
10:16 danvet: and we can always readd epxlicit checks again or something like that
10:16 javierm: tzimmermann: Ok, I'll look at that too. Thanks
10:16 tzimmermann: danvet, what?
10:17 danvet: tzimmermann, or why are we talking about DRIVER flags now again?
10:17 danvet:maybe just confused
10:18 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
10:18 tzimmermann: so it can ignore simpledrm and possibly others
10:19 tzimmermann: and we can print driver names as well
10:21 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
10:21 javierm: danvet: there's no way for the DRM core right now to differentiate between simpledrm or any other DRM driver
10:22 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
10:30 danvet: javierm, tzimmermann won't this be a bit a chicken&egg?
10:30 danvet: at least for some drivers you might not have the drm_driver yet at the top of probe
10:30 danvet: but maybe none are this backwards
10:37 javierm: danvet: hmm, those are the ones using the component framework right ?
10:37 javierm: those then should call this helper function in their .bind callback
10:39 gawin: JoshuaAshton: about MR with malloc(0), you wanna keep code just for BVH?
14:01 Newbyte: What was the reasoning behind this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13238
14:34 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
14:35 javierm: because vgacon is bool but drm is tristate, so when built as a module the nomodeset param will be unknown...
14:35 danvet: javierm, needs a stand-alone file which is always built-in
14:35 danvet: as long as drm.ko is enabled
14:35 danvet: or something like that
14:35 danvet: we have a few other things like that
14:35 daniels: Newbyte: reliability issues
14:36 javierm: danvet: Ok, if a workaround like that is acceptable I can use that approach
14:36 danvet: javierm, that's why I suggested to stuff it into drivers/gpu/nomodeset.c or os
14:36 javierm: danvet: I think we should also add a drm.nomodeset regardless and deprecate the not namespaced nomodeset at some point
14:37 danvet: javierm, uphill struggle against ever blogpost ever
14:37 javierm: danvet: fair
14:37 danvet: not sure you can win that, and it's marginal gains at best
14:37 danvet: as long as we built-in only when drm is enabled I think the few bytes for that kernel option are just fine
14:37 javierm: danvet: nod
14:38 danvet: there's much bigger fish to fry for saving 100 bytes in the image (if it's that much even)
15:31 ajax: getting a little tired of viewperf being treated as a shadow opengl spec
15:34 imirkin: someone just really enjoys optimization :)
16:02 calebccff: Newbyte: probably better asking in #freedreno than here?
16:11 Newbyte: calebccff: that's probably true, wasn't sure where to ask so this felt like a safe bet
16:29 javierm: tzimmermann, danvet: why most of the drivers using vgacon_text_force() also have a module "modeset" param to enable/disable modesetting ?
16:29 danvet: javierm, i915 started, everyone copypastes
16:30 javierm: danvet: gotcha
16:31 danvet: we might be able to just delete the copypasta for most of them tbh
16:31 danvet: for i915 and maybe the amd's there might be too much blog posts around using those
16:32 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
16:33 danvet: javierm, uh that sounds a bit like overkill? just keep that part of the check in drivers?
16:33 javierm: danvet: Ok. Wanted to get rid of the duplicated code but I'm indeed over engineering this :)
16:34 agd5f: danvet, amdgpu doesn't support the modeset option, we just recommend modprobe.blacklist=amdgpu
16:36 javierm: it seems "nomodeset" is also not completely accurate since is not only disabling KMS but also DRM
16:40 MrCooper: javierm: the modeset module parameters were originally for disabling KMS; now that the drivers only support KMS, they're kind of redundant
16:41 javierm: MrCooper: I see
16:41 MrCooper: though another wrinkle is that amdgpu cannot be initialized by any means after booting with nomodeset on the command line
16:41 javierm: sorry if I'm making silly questions, it's just that I'm not super familiar with KMS/DRM
16:42 javierm: MrCooper: that's also true for all drivers that check for the nomodeset param AFAICT
16:42 MrCooper: nothing to apologize for, here be lots of dragons and hysterical raisins :)
16:43 javierm: :)
16:44 MrCooper: at least some drivers can initialize with "modprobe <driver> modeset=1" after booting with nomodeset, but not amdgpu IIRC
16:44 MrCooper: (I actually did that just today with qxl)
16:45 jekstrand: zmike: You know, you could fix the debug situation properly.....
16:46 zmike: jekstrand: I could, but I have other things I'm trying to rush through before I leave on holidays
16:46 javierm: MrCooper: Ah, you are right. Because the check is in the module_init() and not in the .probe handler
16:47 jekstrand: zmike: Fair.
16:48 javierm: MrCooper: scratch that, it shouldn't matter
16:50 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
16:51 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
16:51 zmike: and readability
16:52 MrCooper: javierm: I guess it's because amdgpu doesn't have the modeset parameter
16:52 javierm: MrCooper: yeah, specially since mutter doesn't have an fbdev backend
16:53 javierm: MrCooper: oh, right
16:53 javierm: so the per-module modeset then now makes more sense to me, since one could override the global nomodeset
16:54 javierm: is not only to disable a single driver but also to force enable it
17:03 MrCooper: right, though modprobe.blacklist can be used for basically the same purpose
17:04 javierm: MrCooper: yep, for foobar.modeset=0 but you may still need something like foobar.modeset=1 if nomodeset was used
17:04 MrCooper: yep, nomodeset is kind of bad that way
17:04 javierm: MrCooper: yeah
17:05 MrCooper: though making it a drm parameter which can be changed at runtime should fix that
17:07 javierm: MrCooper: indeed
17:52 jenatali: Anyone (maybe jekstrand) want to ack the hash table commit from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13390 so I can land it?
17:56 anholt: done
18:01 jenatali: Thanks!
18:09 anholt: hmm. now that I've made my conformance package, where do I actually submit it?
18:22 airlied: anholt: for what api?
18:24 anholt: vk
18:25 airlied: are you submittimg as SPI or.goohle?
18:25 anholt: spi
18:25 airlied: then you need to get an adopter login
18:25 airlied: with an @x.org address
18:25 anholt: oh. adopter login, not member login
18:26 airlied: https://www.x.org/wiki/Khronos/
18:27 anholt: ok, I did do member signup
18:28 anholt: ah, and this adopter login path works. (member login for the new account is broken in some weird way)
18:30 airlied: you arent a member only an adopter
18:30 airlied: differwnt levels of access
18:32 anholt: I might expect some kind of 403 in that case, rather than a php unhandled exception :)
18:32 anholt: anyway, I'm in the conformance submission form now, thanks
18:39 emersion: Lyude: do you know if it's possible to use this to access the internal khronos discussions? https://www.x.org/wiki/Khronos/
18:43 airlied: no it's not
18:44 airlied: x.org/spi is only an adopter not a khronos member
18:46 emersion: rip
18:47 emersion: khronos could really be more open than it is
18:47 airlied: not really it's IP agreements that all members sign are pretty limiting
18:48 airlied: so it would be a major undertaking across a lot of legal departments to change it
19:00 emersion: meanwhile, a lot of people are excluded from the discussions
19:01 emersion: and khronos does its stuff behind closed doors
19:05 airlied: emersion: you can be nominated for individual memberships for certain working groups
19:07 emersion: and then get the right to pay $$$?
19:08 emersion: i don't see nominations mentionned anywhere
19:08 airlied: no it's free
19:11 emersion: why the heck is khronos a closed doors thing, while many other standards bodies aren't
19:12 emersion:looks forward to creating the wayland foundation, with paid membership for wayland protocols standardization
19:12 karolherbst: soo.. yeah.. I think I give up on marge-bot for drm stuff
19:12 karolherbst: way easier to script this stuff inside dim
19:13 airlied: emersion: large companies with lots of lawyers started it, and they talk about things none of them want to talk about
19:13 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?
19:13 airlied: the IP framework lets them talk about them without having to sue each other over patents every week
19:13 airlied: karolherbst: we do tagging via scripts now
19:14 karolherbst: mhh, true
19:14 karolherbst: anyway.. having a dim subcommand now which pulls trees, adds weirdo tags and repushes the tree
19:15 karolherbst: just need the MR id as an arg
19:15 karolherbst: added r-by tags from approvers today
19:16 karolherbst: and it doesn't have the problem like marge, which just replaces old tags
20:12 danvet: karolherbst, doesn't that have the downside that you still need dim around?
20:12 danvet: or do you think of some kind of dim bot that does that like marge
20:14 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
20:15 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
20:15 karolherbst: here is the change btw: https://gitlab.freedesktop.org/karolherbst/maintainer-tools/-/commit/289ccaa530011401c3c3ed7d89e244f3fc4073d1
20:16 karolherbst: the main problem I see with marge-bot are just those corner cases and me thinking we might have to carry most of the changes :/
20:16 danvet: karolherbst, yeah if we have to fork it then a few dim patches sounds good
20:16 danvet: and might indeed make the transition for committers/maintainers a bit easier
20:18 karolherbst: the only thing this requires is to create this gitlab config file, but we could script it with dim as well :D
20:20 karolherbst: danvet: the only thing this approach requires users to make some kind of email public in gitlab
20:20 karolherbst: but we would have the same problem with marge or we grant marge admin access to gitlab, which I think is a stupid idea from a sec pov
20:21 danvet: yeah I think public mail is acceptable to make this work
20:21 danvet: well for approvers/reviewers at least
20:21 karolherbst: yeah, well
20:21 karolherbst: I mean.. people writing commits also have their email public inside git, soo...
20:21 karolherbst: we just have to nudge people setting it up
20:22 karolherbst: the only "regression" I see compared to downloading patches from patchwork is per commit tags
20:23 karolherbst: and I think there is some mechanism in gitlab to purge all approvers on pushes to the source branch or something.. but well
20:34 danvet: karolherbst, oh you bake it all into the merge commit?
20:36 karolherbst: danvet: ehh no, I put the tags on each commit
20:36 karolherbst: still doing linear history within nouveau
20:37 karolherbst: I meant, if one reviewer replies and says commit A, C and F are reviewed or something
20:38 danvet: karolherbst, ah yeah that stuff is not scriptable
20:38 danvet: also I think the only thing we really need is the per-commit Link: tag to the MR
20:39 danvet: or at least without getting screamed at
20:39 karolherbst: yeah. doing this as well
20:39 danvet: apparently there' is already a bridge to get gitlab MR updates flowing into lore
20:39 danvet: well not lore, but public inbox, which is what lore.k.o runs
20:39 karolherbst: so I add Link: to the mr, Signed-by-off: of the person using dim and Reviewed-by: of each approver with a public email on each commit
20:40 karolherbst: and then at the end it gets pushed into the source branch
20:41 danvet: well for git blame and that Link: on each commit would be nice
20:41 danvet: like the Part-of: stuff
20:41 karolherbst: yeah
20:41 karolherbst: exactly like that
20:41 danvet: karolherbst, oh that scrip itsn't public it seems, but your employer has it
20:41 karolherbst: yeah.. might be
20:41 danvet: karolherbst, https://lwn.net/Articles/871237/ <- search for public-inbox here
20:42 jenatali: airlied: The IP framework is also the reason that I'm explicitly not allowed to participate in any working groups
20:44 karolherbst: ehh.. now I pushed it without wanting to :D
20:44 karolherbst: anyway
20:45 karolherbst: result can be seen here: https://gitlab.freedesktop.org/drm/nouveau/-/commits/staging/nouveau-fixes/
20:45 karolherbst: still contains the old patchwork links, because that's where I got the patches from
20:45 karolherbst: top 4 commits
20:45 karolherbst: it also doesn't add duplicates and stuff
20:46 airlied: jenatali: yeah it's probably a big ask for the main API competitor to sign it :-P
20:47 jenatali: Yeah, even though we were implementing their specs
20:47 jenatali: We had to schedule special out-of-IP-framework meetings to be able to talk about things. Was kinda ridiculous :)
20:47 jenatali: Hooray for lawyers
20:47 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...
20:48 danvet: karolherbst, I think if rh has the script, it would be good to shovel it a k.o folks for appeasement
20:48 danvet: so if you can get that released with a proper license
20:48 airlied: jenatali: yeah just nobody wants you contributiing back to those specs :)
20:48 airlied: too many patents :-P
20:48 jenatali: Yeah
20:49 karolherbst: danvet: ahh.. I see
20:49 karolherbst: I think bentiss is the better person to talk about this though
20:49 danvet: oh bentiss was involved in setting this up?
20:50 karolherbst: not sure, I just know bentiss was more involved in the kernel ci and gitlab stuff than I was
20:50 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
20:51 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 :/
23:13 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?
23:16 airlied: karolherbst: currently the submitter usually decides
23:16 airlied: so the tag should be there before gitlab
23:17 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
23:17 karolherbst: just curious what we should do about that formal requierement
23:19 airlied: no we don't send the patches to stalb
23:19 airlied: stable
23:19 airlied: if you actually send patches to stable, you get a gregkh "this isn't how this works" email
23:20 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?
23:20 karolherbst: ahh...
23:20 airlied: pretty much
23:20 karolherbst: I just greped for stable, so found a note, but maybe I missinterpreted it
23:21 airlied: https://www.kernel.org/doc/html/v4.17/process/stable-kernel-rules.html#stable-kernel-rules
23:21 karolherbst: yeah.. okay
23:21 karolherbst: nvm then
23:25 jenatali: Hooray I think I finally have justification to be able to spend some time on hooking up tc
23:25 karolherbst: tc?
23:26 jenatali: Threaded context
23:27 karolherbst: ahhh, cool