00:33 hwentlan: danvet, reviewed. for the DC atomic rework we still got two patch sets in progress but i might take you up on your offer to trade reviews in 2-3 weeks.
00:35 hwentlan: danvet, feel free to ping me with review requests again... i think it's important we become more active on dri-devel. this helps me justify it to management (we help them, they'll help us)
00:35 whompy: As a user, this makes me very happy to support AMD btw. If happy user comments mean anything to management.;)
00:57 MrCooper: hwentlan: danvet isn't here right now
02:26 hwentlan: MrCooper, thanks. didn't notice because I'm usually online even when away (thanks to irccloud). I'll just ping him tomorrow
03:53 imirkin: pq: btw, i suppose there's some good reason you don't just use /tmp like every other application under the sun?
03:54 airlied: imirkin: XDG_RUNTIME_DIR?
03:54 imirkin: ya
03:56 airlied: imirkin: I believe XDG_RUNTIME_DIR has different semantics to /tmp
03:56 imirkin: ah ok
03:56 airlied: and most applications use of tmp is probably racy :-P
03:57 imirkin: meh. mkdtemp / mkstemp probably cover most use-cases
06:28 danvet: hwentlan, btw I'm trying to documenting locking rules in kernel doc comments
06:28 danvet: did you check those, or are they lacking?
06:28 danvet: oh, they're lacking :(
06:29 danvet: hwentlan, want to type the patch to fix that?
06:29 danvet: crtc->state is protected by crtc->mutex
06:29 danvet: plane->state by plane->mutex
06:29 danvet: and connector->state by mode_config->connection_mutex
06:30 danvet: I generally try to add "Protected by ..." and "Protects ..." comments for the big things in the lockings cheme
06:30 danvet: *scheme
06:43 danvet: airlied, can you pls backmerge -rc4
06:43 danvet: we need it for gvt in i915
06:43 danvet: or should I backmerge -rc4 directly into i915?
06:45 pq: imirkin, /tmp is not guaranteed to be a tmpfs. XDG_RUNTIME_DIR specification has many requirements which are good. But if your /tmp is a tmpfs and you make a per-uid directory in there protected from anyone else, you can point XDG_RUNTIME_DIR there. It's just that Weston cannot assume /tmp is ok. If it happened to be nfs, that'd be really bad. If it's regular disk, it's workable but not good.
06:49 airlied:brings the pain
06:50 pq: keithp, I thought all the transformation etc. all the way to the final framebuffer would be most efficiently rendered in the application process. E.g. if you need image warping because of HMD lens distortions, it'd be fastest done to geometry before rasterization, but that obviously needs careful integration with the game engine. But I totally understand the appeal of doing things in post-process.
06:50 airlied: danvet: yay gvt conflicts all over the place :-P
06:50 airlied: pq: it's done in both
06:50 danvet: airlied, :-)
06:50 airlied: and sometimes undone and redone in the compositor
06:51 danvet: I haz merge resolution in drm-tip, tested ....
06:53 airlied: danvet: won't that be backwards for me though, since you pull -next into Linus?
06:53 airlied:goes to steal it
06:54 danvet: yeah the columns are the other way round
06:54 danvet: hm, wait
06:55 MrCooper: pq: the VR compositor has to re-project the application's image if the application misses the deadline for its next frame, to prevent the user from getting sick
06:55 danvet: we have a bikeshed once every year whether it's better to merge -fixes into -next or the other way round
06:55 pq: airlied, I'm struggling with the concept of a compositor here, since it's not compositing anything, is it? It's just transforming a single image at most. And I know about re-tweaking the rotation just before presenting, but that also could just be in the (libraries used by the) app.
06:55 danvet: airlied, yeah we pull -next into -fixes, so other way round from you/backmerges in general
06:55 danvet: git rerere still gets it
06:56 MrCooper: pq: the app process likely lacks the credentials to make sure the reprojection makes the deadline
06:56 pq: MrCooper, So far when I have claimed that it's ok to go through a display server for presenting to HMD, I've been told it adds too much latency. And now one is actually introducing an new process.
06:57 MrCooper: a very specialized one
06:57 pq: MrCooper, um, isn't that exactly what keithp is going to fix?
06:58 MrCooper: don't think so? E.g. high priority GPU scheduling will only be available to root, at least initially
06:58 airlied: pq: the problem is you need to keep the hmd moving even if the game stops to consume CPU
06:58 airlied: or compile shaders
06:58 airlied: if the game stalls the compositor can at least transition to a waiting room
06:59 pq: ok, that's a nice idea
07:00 pq:has a DK2 on his desk, has not touched it for months due to crap image quality.
07:03 airlied: pq: the main thing is you don't want that compositor having another frame of latency due to the system compositor
07:03 airlied: you also want it running at a higher gpu priority than the desktop compositor
07:03 airlied: danvet: okay throwing it into a build
07:04 MrCooper: s/the desktop compositor/any normal process using the GPU/
07:15 pq: airlied, that's all arrangeable and I would like to implement that in Weston while it is also driving the desktop, just to show it's ok. But no time and all that. I already wrote a draft design how Wayland would fit in, without any DRM resource splitting in the kernel.
07:16 MrCooper: pq: weston cannot get high priority GPU scheduling without root
07:17 pq: my idea is based on Weston purely just driving the flips, no GPU work, making it easy to swap between multiple VR apps.
07:18 pq: MrCooper, I wasn't aware such scheduling even existed :-)
07:18 airlied: pq: are you talking about having weston undirect the other compositor?
07:18 airlied: I've seen discussion on mutter about doing that
07:19 pq: where's my write-up...
07:19 airlied: then you just have the latency for the flip
07:19 airlied: not any rendering
07:21 pq: https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2
07:21 pq: airlied, yes
07:21 pq: essentially to just get over not having the DRM resource splitting in the kernl
07:22 pq: but since that's now coming, my plan is kind of moot
07:22 pq: FWIW, there was a proposal for regular fullscreen, scanout-able Wayland clients being able to hit the same low-latency optimizations as that plan would have for HMDs.
07:23 airlied: pq: the main reason for doign resource splitting is not relying on every DE to get this right
07:23 pq: i.e. if you know it's scanout-able and there is nothing else to composite, just ignore the usual timings and program the app flip ASAP
07:24 airlied: fixing X, weston, mutter, kwin, e, unity etc
07:24 pq: airlied, well... I'm personally very cautious of promoting "let's bypass the display server because it probably doesn't know what it's doing"
07:25 pq: there are very loud people demanding that the applications must be given full control of e.g. all color management related features completely bypassing the display server, because it surely cannot implement things right
07:26 pq: i.e. plumb gamma tables and everything KMS API exposes for color stuff directly through to apps...
07:26 pq: of course that is an extreme example, because there are many apps simulatenously. At least for HMDs you can reasonably assume there is only a single app at any one time.
07:27 MrCooper: pq: https://lists.freedesktop.org/archives/amd-gfx/2017-March/006106.html
07:29 pq: MrCooper, interesting.
07:29 pq: something I could have used around 2008... :-)
07:31 pq: anyway, very happy these things are being worked on!
07:31 MrCooper: don't think the hardware of that time was anywhere near the capability yet :)
07:31 pq: right :-D
07:35 airlied: danvet: so we have two backmerges in a row :-(
07:35 airlied: I'm guessing that is something Linus would dislike
07:35 airlied: so let's try to avoid it in the futyre :)
07:36 MrCooper: danvet: will 1 global cursor plane work when the cursor is visible on multiple CRTCs?
07:42 airlied: danvet: pushed out now
07:56 danvet: airlied, thx
08:30 MrCooper: danvet: did you see my question above?
08:30 danvet: MrCooper, missed, but what's the context?
08:30 danvet: vmwgfx?
08:31 MrCooper: yep
08:31 danvet: well, it already doesn't work since there's only 1 cursor :-)
08:31 danvet: but atomic userspace might now realize that
08:31 danvet: if you just use legacy cursor ioctl it'll flip-flop the cursor plane back&forth
08:32 danvet: which is exactly the behaviour we already have
08:32 danvet: so I think it should work
08:32 danvet: but haven't tested it ofc
08:37 MrCooper: that doesn't sound like the expected behaviour with clone mode or when the cursor is at the edge between monitors
08:38 MrCooper: maybe it'll work out anyway due to how the vmwgfx hardware works
08:39 danvet: yeah, current vmwgfx cursor isn't really working how it's supposed to
08:39 danvet: but the way it seems usually set up means it's not obviously broken
08:40 danvet: but if you use the cursor plane for any surface, not just cursors
08:40 danvet: it'll fall apart
08:40 danvet: and it probably is already falling apart in the corner cases you've mentioned
08:41 MrCooper: I'm just wondering if having only a single global cursor plane wouldn't result in userspace thinking it can't make use of that in cases where the cursor needs to be visible on multiple CRTCs, even though it might actually work out due to how the hardware works
08:42 MrCooper: my understanding is it works fine now in practice, as long as the vmwgfx kernel/hypervisor code has accurate information about how the outputs are laid out
08:43 MrCooper: and as long as that's equivalnet to having a single cursor in a single framebuffer
08:44 MrCooper: (which should always be the case with Xorg)
09:21 danvet: hwentlan, well I started typing :-) http://paste.debian.net/924716/
12:56 Hi-Angel: Channel logs for many previous years disappeared, that's so sad :( They start now since 2015.
14:11 danvet: sumits, padovan is around too
14:11 danvet: meanwhile enjoy your time off :-)
14:16 robher: robclark: btw, something in your branch (or next) breaks all virtio. Bisecting it now.
14:18 robclark: hmm, does virtio use iommu somehow? The iommu-probe-defer stuff seemed to break some things (there was some discussion on msm kernel list)
14:18 robclark: wasn't really virgl but iirc it was something related to virt, so possibly related..
14:20 robher: robclark: probably does. It's not just virgl, but any virtio device.
14:21 robclark: I didn't check the latest discussion about it, maybe there is a fix by now.. I'm defn not on most recent iommu probe-defer patches until I have time to rebase again (ie. probably not this week)
14:27 imirkin: pq: feels like the kinds of restrictions one would expect from embedded software. if i want to put /tmp on nfs, that's my prerogative, and i get to suffer the consequences. seems like /tmp is a perfectly fine fallback. well, wtvr - i guess i'm just outside the intended audience for the software. i thought it was targeted at developers to use as a reference impl.
14:27 devilhorns: when using multiple hardware planes and assigning FBOs to them, how do we deal with z-order ?? In older times, some drivers (exynos) had to use a custom ioctl to be sure the cursor plane was above the primary plane. Is that still an issue these days ? or is z-order handled by the driver ??
14:27 robher: robclark: you're on v8 of the series?
14:30 danvet: devilhorns, we have a standard for the z property now, but most drivers probably implement it wrongly or not at all
14:30 danvet: so yeah, if you overlap planes you either need to know how your driver works
14:31 danvet: or check/set that new z property
14:31 devilhorns: danvet, and the z prop is on the plane object ? or where would I find that ?
14:31 devilhorns: because when I print out plane properties here, it makes no mention of zorder property
14:31 robclark: robher, tbh not sure what version I'm on.. probably whatever was current about a month ago
14:32 devilhorns: or perhaps I don't have a new enough kernel/libdrm....
14:33 pq: imirkin, well, you are suffering the consequences of managing to run a distro that does not set up XDG_RUNTIME_DIR at this day and age. :-)
14:34 imirkin: pq: yes, gentoo is quite the oddity.
14:34 pq: imirkin, /tmp is only a fine fallback *if* it is tmpfs.
14:34 pq: imirkin, I run gentoo, too.
14:34 imirkin: pq: so it doesn't work on !linux?
14:34 pq: we have non-linux users??
14:34 robclark: devilhorns, yes, it is a plane property (if driver supports it.. shouldn't be libdrm version dependency but could be kernel version dependent)
14:34 devilhorns: robclark, ahh ok. thank you :)
14:34 devilhorns: danvet, thank you for your time !! :)
14:34 robclark: np
14:34 imirkin: pq: apparently not :) althoug netbsd and freebsd do import the drm stack
14:35 daniels: but not the input stack
14:35 daniels: or the bits which lets us run without being suid root
14:36 imirkin: either way, it seems that people like me are outside the target audience. i'll crawl back into my hole now.
14:38 pq: imirkin, oh no, you are in the audience. Why else would we maintain two other ways to run weston-on-DRM than the one that uses logind? ;-)
14:40 imirkin: pq: ok, well if i'm the audience, use /tmp and don't make me deal with udev.
14:40 pq: oh wow, udev, didn't realize that
14:41 imirkin: i *have* udev, i just don't know how to operate it, and hope to go through life without acquiring that knowledge
14:41 imirkin: so configuring extra "seat" variables is well beyond my desires
14:42 imirkin: all i know about udev is i need to touch some file in udev.d to prevent it from fucking up my interfaces
14:43 pq: ok, so the card selection...
14:44 imirkin: yep. personally, my advice would be to add cmdline switches for all the things you pull out of udev/environment and allow overrides.
14:44 daniels: imirkin: you don't need to touch udev configuration or change anything about seats. what you're asking for - an extra feature to be able to pick a device by path (a feature nothing else has aiui) - sounds entirely reasonable to me, but given how snippy you've been throughout the whole thing, i have no motivation to work on it.
14:45 danvet: devilhorns, https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
14:45 imirkin: daniels: Xorg has it with the BusID
14:45 danvet: it's the in-kernel driver interface doc, but about the best we have wrt all these various properties
14:45 devilhorns: danvet, thank you :)
14:45 imirkin: daniels: i wouldn't expect you to work on things for just me.
14:45 danvet: if it's not properly documented in there you can assume it's probably a horror show of driver dependent behaviour :(
14:46 imirkin: daniels: and afaik, you have it, with --seat - but that requires udev work. [and it makes sense, if you legit want separate seats on a single box]
14:52 imirkin: [and while i didn't mean to be snippy, i'm frustrated with the situation, and it likely shows through my commentary.]
15:06 hwentlan: danvet, i like your doc patch. even if it's just a start i think it clarifies things sufficiently to warrant merging it. feel free to add my r-b
15:10 hwentlan: danvet, in regard to your offer to trade review time. no need to look at DC atomic rework yet... we still got a couple patches in progress that i'd like to get out first to make your time worthwhile. i'll ping you probably in 2-3 weeks
15:19 danvet: hwentlan, I'll take that r-b, thx a lot
15:23 pq: imirkin, here, the two top commits are for you: https://git.collabora.com/cgit/user/pq/weston.git/log/?h=cardsel
15:25 pq: imirkin, unfortunately you get to solve the XDG_RUNTIME_DIR problem yourself. It's been years and we still have not come up with any fallback that would fill the criteria. We really prefer the user to shoot his own foot with it, not us pulling the trigger.
15:30 pq: imirkin, a Tested-by would be appreciated.
15:30 pq: till tomorrow .o/
16:05 imirkin_: pq: so ... i still haven't heard what the downsides of pointing it at /tmp are. note that i have no clue what it's used for, i'm just not particularly aware of use-cases that REQUIRE tmpfs. are you mmap'ing files or something?
16:06 imirkin_: pq: also, is the /dev/dri implied there for the card name? (i'd definitely prefer typing in a full path personally - tab completion is nice - but not required)
16:09 daniels: imirkin: we are mmap'ing files, indeed
16:10 daniels: imirkin: i believe /dev/dri is implied in that option
16:11 imirkin_: daniels: and i suppose some compelling reason against using shm?
16:11 imirkin_: [i assume these have to be shared with other processes somehow, otherwise you'd just be using anonymous maps]
16:12 daniels: imirkin_: posix shm lifetime sucks, as it's a handle which needs to be explicitly destroyed; passing fds across processes does the right thing for lifetime
16:12 imirkin_: urgh
16:14 imirkin_: and in any case, i take it's part of the "regular" wayland protocol?
16:14 imirkin_: the fd passing aspect of it, that is
16:15 imirkin_: btw, i suspect i know why i don't have XDG_RUNTIME_DIR set
16:15 imirkin_: some joker forced gdm to become a full-on gnome app and use gnome-shell, so i just haven't upgraded past gdm 2.x. and i guess this XDG stuff wasn't a thing at the time
16:15 imirkin_: on this box, where i use lightdm, it's set
16:16 daniels: generically, passing fds is a protocol primitive; specifically, the dmabuf protocol uses it, as does wl_shm for software pixmaps (also keyboard layout maps use it)
16:16 daniels: XDG_RUNTIME_DIR is more of a logind thing, on those systems https://www.freedesktop.org/software/systemd/man/pam_systemd.html
16:17 imirkin_: ah. and logind is part of systemd right?
16:17 daniels: the primary implementation of the logind api is part of systemd, yeah
16:17 daniels: (on vanilla fedora/debian installs, you get $XDG_RUNTIME_DIR set even at a VT)
16:17 imirkin_: interesting. well i definitely don't have systemd on this box, but i have the XDG_RUNTIME_DIR set. someone's setting it.
16:18 imirkin_: the main diff i can think of between this box and my home one is lightdm vs old-gdm
16:18 daniels:shrugs
16:23 imirkin_: pq: btw, to complete it, you could also add --input= or something to specify a list of /dev/input/event*'s to process
16:23 imirkin_: [i don't need that functionality, just seems logical to add]
16:25 imirkin_: pq: i won't be able to test anything until tonight btw, and might not even be able to get to it tonight at all.
16:27 pq: imirkin_, no worries, we have patch turn-around times sometimes measured in months.
16:30 imirkin_: ouch!
16:34 pq: imirkin_, to recap just in case, you can launch weston with: 'weston --device=...' as root in a VT, 'weston-launch -- --device=...' as a user in a VT, or 'weston' as a user in an X terminal.
16:35 imirkin_: any particular reason i can't launch it as root from X (targeted at another card)
16:35 pq: I never tried it, but I suppose it expects to be managing the VT and VT-switching, so it'll probably break something.
16:36 imirkin_: ohh... Xorg has -novtswitch :)
16:36 imirkin_: (and -sharevts)
16:36 pq: also, it'll pick the x11-backend unless you force it to DRM when running on a X terminal
16:37 imirkin_: good to know.
16:38 imirkin_: (i usually run a second Xorg on the "other" GPU, which often has a S-Video output, which my monitor lets me picture-in-picture with the main image)
16:38 pq: I don't know what those VT options should do with and without logind
16:39 imirkin_: and both X servers get the same input, which can be a little confusing at times, but it's manageable
16:39 pq: oh yeah, input would be a problem
16:39 imirkin_: well, as long as you're aware of it, it's fine
16:39 imirkin_: it was a bit of a surprise the first time
16:40 imirkin_: i don't run a WM or anything like that on the second Xorg, just applications directly
16:41 pq: I'd really say it's completely unacceptable - at least if it worked as a user with weston-launch, and to prevent that I don't even know how.
16:41 imirkin_: wellll... i only have one keyboard, and no mind-reading software to indicate which one of the X servers i want to send my input to
16:42 pq: exactly
16:42 pq: there could be a --no-input, though
16:46 pq: wonder how complicated it would be to support 'weston --device=... --no-input --no-vt' as root, and ensure it cannot be used with weston-launch... seems a bit of a stretch if there's no heavy use for it
16:53 imirkin_: pq: well ... you still want input :) that's the tricky bit.
16:53 imirkin_: pq: i think just taking regular input would be fine, like the situation i described
16:53 imirkin_: pq: that said, having a --input= where you can specify a list of event devices to listen on would make it even more flexible
16:54 imirkin_: the main thing with X is that it "turns off" when its VT isn't active anymore, which doesn't work for the "2 at a time" thing
16:54 daniels: imirkin_: not being funny, but it sounds like you could really benefit from another machine ... ?
16:55 daniels: yeah, -sharevts is a screaming nightmare
16:55 imirkin_: daniels: yes, in principle, i definitely would
16:55 imirkin_: daniels: however it goes counter to my mandate of "having less shit"
16:57 daniels: physically yes, but it's a vast technical simplification at least :)
16:59 imirkin_: yeah. esp for kernel work :)
17:03 robertfoss_: robclark: How do I make sure that EGL_SYNC_NATIVE_FENCE_ANDROID is enabled for virgl? Where can I toggle the extension on/off?
17:04 robclark: hmm, in theory virgl should advertise it if kernel version is new enough.. not really something you (as a user) can toggle on/off..
17:04 robclark: (but possibly not understanding what you are getting at)
17:05 robclark: imirkin, btw for compute shaders, do you ever have texture sampler state?
17:05 robclark:not seeing registers for that, but perhaps that makes sense..
17:05 imirkin_: robclark: yes
17:06 imirkin_: compute shaders can sample textures. there were regs on a4xx...
17:06 robclark: umm, not quite what I'm getting at..
17:07 robclark: ie. we have pipe_sampler_view state but not pipe_sampler_state
17:07 imirkin_: robclark: we should :)
17:07 imirkin_: sampler state includes a bunch of useful things related to sampling things.
17:08 robclark: I guess I should be using something other than imageLoad() then?
17:08 imirkin_: imageLoad is for getting data from images
17:08 imirkin_: not for sampling textures
17:08 imirkin_: texture() to sample from textures
17:08 robclark: oh, I guess gl compute shader, I should be able to use all the normal texture sample stuff..
17:08 robclark: right
17:09 robertfoss_: robclark: I'm just seeing logcat errors complaining about the extension being missing: https://hastebin.com/numinobare.css
17:09 robertfoss_: robclark: I dont think I've seen that on freedreno. just virgl
17:09 imirkin_: robclark: images are pretty different from textures in terms of API and other implications.
17:09 robclark: robertfoss_, oh, I think that is "normal" android bonghits..
17:09 robclark: the gles shim layer hides the extension, even though it is there
17:11 robclark: imirkin, you are assuming I have half a clue about compute shaders.. r/e'ing (and righting hacky programs to dump blob cmdstream) is how I learned gl :-P
17:11 imirkin_: robclark: same here :)
17:11 imirkin_: robclark: oh, i also cheated and read some specs. but only under the most dire circumstances.
17:12 robclark: heheh, same here
17:13 imirkin_: anyways, long story short, images != textures. compute shaders have both. in ES, no other stages are required to support images, but most do in at least frag shaders (as that's required by AEP iirc)
17:16 robclark: ahh, there we go..
17:17 robclark: hmm, wonder how a5xx does image writes then if it must be a thing in FS..
17:19 imirkin_: well there's a limit on the number of MRT's + image outputs in FS
17:21 robclark: hmm, fun.. so maybe they are still re-purposing MRTs
17:21 HdkR: That would be interesting
17:22 imirkin_: i really should go back and do proper RE on images on a4xx
17:22 robclark: HdkR, well, that is what they've done since a3xx.. which I think will make some of the driver logic fun..
17:22 imirkin_: now that i have a better appreciation of how they're supposed to work
17:22 HdkR: imirkin_: Don't most hardware vendors just implement images as global memory loadstores?
17:22 imirkin_: HdkR: dunno. not on nvidia.
17:22 HdkR: huh
17:23 HdkR: What does Nvidia do?
17:23 imirkin_: depends on the gen
17:23 imirkin_: maxwell is actually relatively well-behaved
17:23 HdkR: Maxwell would be interesting
17:23 imirkin_: except for MS images, you can hand it an image descriptor + coordinates, and expect things to work
17:24 HdkR: huh
17:24 imirkin_: previous gens you have to do some amount of mapping things into 2D coordinates
17:24 imirkin_: using specialized ops
17:24 imirkin_: and then hand them to a more generic surface load/store instructions
17:25 imirkin_: (which do operate on global memory, but are separate from the plain load/store global ops)
17:26 HdkR: Interesting
17:26 imirkin_: and fermi is binded, so it works a little more like maxwell
17:26 imirkin_: but has no provisions for 3d images
17:31 imirkin_: daniels: anyways, while i agree that sharevts is disgusting, it actually works very nicely for my use-case.
17:48 daniels: imirkin_: it's much easier when it's someone else's problem, heh
17:49 imirkin_: *so* much easier
18:03 dv_: hi
18:04 dv_: I cloned the mesa3d git repo , and want to see the commits that were added since the 17.0.1 release
18:04 dv_: but there are no tags or branches or commit messages with version numbers
18:05 imirkin_: there's a 17.0 branch
18:05 imirkin_: and a mesa-17.0.1 tag
18:05 imirkin_: (and a mesa-17.0.2 tag, etc)
18:05 dv_: oh?
18:05 dv_: hm wait
18:05 dv_: ah, that's the reason - this is actually a forked repo :)
18:05 dv_: *duh*
18:06 imirkin_: https://cgit.freedesktop.org/mesa/mesa/log/?h=17.0
18:06 imirkin_: you can also look at the release notes, e.g. https://www.mesa3d.org/relnotes/17.0.2.html
19:58 Avengence: libdrm assumes that the minor number of device nodes under /dev/dri matches the numeric suffix of the node's name. unfortunately, that assumption is not valid for all platforms
19:59 Avengence: looking through the history, it appear that the name of the device node was previously used, but a few versions back the drmOpen* functions were changed to use major and minor numbers instead with that assumption embedded. I am curious waht the motivation was for that.
20:16 austriancoder:looks for a rb: https://patchwork.freedesktop.org/patch/146460/ :)
20:50 rliou92: Hi guys, I'm interested in applying for Google Summer of Code. I'm a beginner looking where to start. I would like to prove myself by submitting a patch. There are so many projects, all of which are seem daunting to me. Would anyone like to guide me towards a project? I would greatly appreciate it.
21:00 mattst88: rliou92: most projects in this area are hardware dependent. what hardware do you have?
21:04 rliou92: mattst88: I have a desktop with a Radeon GPU and an Acer 720 chromebook.
21:06 kisak: ^Acer c720 is an intel haswell
21:08 kisak: saying Radeon like that covers all ATi and AMD hardware from the last 17 years
21:13 rliou92: Ok, to be more specific it is HIS IceQ Boost Clock Radeon HD 7950 DirectX 11 H795QC3G2M 3GB 384-Bit GDDR5 PCI Express 3.0 x16 HDCP Ready CrossFireX Support Video Card
21:14 mathstuf: hi, im trying to build mesa on windows from the tarball but am hitting errors about mako and lex not being available
21:15 mathstuf: the docs say they shouldn't be necessary, though looking at the sconscript, i see no logic to handle it already being generated
21:24 mathstuf: i have to head out; ill be back in the morning though
22:33 Kayden: x.org elections are now open! https://www.x.org/wiki/BoardOfDirectors/Elections/2017/ https://members.x.org
22:47 kisak: Vote for Kodos and Kang