00:15 dboyan_: tarceri: it's the piglit one
00:19 tarceri: dboyan_: I'm not seeing the crash. Where in Mesa are you seeing the segfault?
00:19 tarceri: in the shader cache code?
00:21 dboyan_: tarceri: write_shader_parameters in glsl/shader_cache.c
00:22 dboyan_: tarceri: the line blob_write_string(metadata, param->Name) where param->Name is NULL
00:22 dboyan_: and it segfault in the strlen() afterwards
00:29 imirkin: whompy: thanks!
03:47 mattst88: tarceri: have you seen https://bugs.gentoo.org/show_bug.cgi?id=613644 before?
03:47 mattst88: I know https://bugs.freedesktop.org/show_bug.cgi?id=97967 was fixed in 17.0, so it must be a different bug
03:55 tarceri: mattst88: possibly. There have been a few different fixes in Master.
03:55 tarceri: IMO we should probably just disable the test in the stable branch rather than trying to backport fixes, because nothing uses it in the current release
03:56 mattst88: yes, I think we need to bring back the --disable-shader-cache flag
04:01 tarceri: mattst88: anyway I think this one should help fix it: https://cgit.freedesktop.org/mesa/mesa/commit/?id=c2793e2c890b828c6cb1e9694619255d69a2ca1e
04:02 mattst88: thanks, I'll ask the reporter to test
05:15 dboyan_: tarceri: Seems that gl_program_parameter.Name can be null, see _mesa_add_typed_unnamed_constant. I was getting the crash on nouveau so i doubt if it is the cause or something else is going wrong here
06:29 danvet: daniels, https://bugs.freedesktop.org/show_bug.cgi?id=89906
06:29 danvet: seanpaul, j4ni ack for Lukas in drm-misc so he can push vga-switcheroo patches?
06:29 danvet: he's defacto maintainer already anyway :-)
06:48 danvet: tomba, btw I think the vblank cleanup code might have been leftovers from when the core didnt' clean up vblank events ...
06:51 tomba: danvet: very likely, it's from the very first omapdrm commit
06:53 tomba: danvet: what's the patch for this "shut down all crtc
06:53 tomba: before unloading" helper you mentioned
06:53 tomba: oh, "Introduce drm_atomic_helper_shutdown" I presume
06:55 danvet: yeah, I needed a backmerge before I can apply it
06:55 danvet: it should fit now
06:59 pq: imirkin, the problem with XDG_RUNTIME_DIR is that is it specified such that Weston cannot itself provide a fallback, it has to be provided by the OS. And most OSs nowadays do provide it for quite some years now. It's been around for at least 5 years.
07:00 pq: imirkin, but all you really need to do is to export XDG_RUNTIME_DIR=/some/tmpfs/$uid before launching 'weston' in an X11 terminal.
07:05 pq: imirkin, you'll have to find a better void to shout at next time :-P
07:28 danvet: hwentlan, do you have time to review "[PATCH 00/19] wire acquire ctx through legacy modeset paths"?
07:28 danvet: I could trade some amdgpu atomic review bw in return :-)
07:29 danvet: if you do, skip 6-8 since those are the driver-specific ones
07:29 danvet: tagr, ack on "[PATCH 07/19] drm/tegra: Don't use modeset_lock_crtc"?
08:03 pinchartl: danvet: there's a message from you in my away log about lvds encoder, but I don't have the context
08:05 danvet: pinchartl, suggested to anholt to reuse parts of it for something he needs for the pl111 driver
08:06 danvet: maybe as a helper library or something
08:06 pinchartl: danvet: is there a mail thread on dri-devel about that ?
08:06 danvet: so that you can keep your lvds encoder, while we reuse all the implementation code to map a panel into a bridge :-)
08:06 danvet: maybe
08:06 pinchartl: as explained before, we should not do that
08:06 pinchartl: give me a few days to handle my e-mail backlog
08:06 danvet: you will keep your lvds encoder
08:07 pinchartl: then I'll be avalable to talk about it
08:07 danvet: I will just steal the bridge vtable
08:07 danvet: and you can always override that again in your lvds encoder
08:07 danvet: pinchartl, [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111
08:08 pinchartl: I'll add it to my e-mail backlog :-)
08:08 danvet: pinchartl, I hope you don't object to extracting useful helpers :-)
08:09 pinchartl: danvet: I know how I'd like the bridge/panel interaction to be handled
08:11 danvet: pinchartl, differently than in lvds encoder?
08:12 pinchartl: yes, in a more generic way
08:12 pinchartl: please give me a few days, I'm drowning under e-mails after two weeks offline
08:13 danvet: hm, now I'm a bit confused
08:13 danvet: my recollection of the lvds encoder discussion was that you objected to doing that
08:13 danvet: I guess I'll wait to be surprised :-)
08:14 danvet: j4ni, http://paste.debian.net/924544/ missing something?
08:14 danvet: should I add "take the blame"?
08:15 danvet: j4ni, and ack on lukas wunner? seanpaul said he's on vacation ...
08:15 pinchartl: danvet: my point was that your approach wasn't generic enough :-)
08:16 danvet: hm, forgot them backmerges
08:19 j4ni: grammar: Maintainer's mostly provided services to keep drm-misc running smoothly
08:19 danvet: http://paste.debian.net/924547/
08:20 j4ni: first bullet: * apply patches
08:20 j4ni: ;)
08:21 danvet: that's what we have committers for I thought!
08:21 danvet: *mostly provide _additional_ services
08:21 danvet: to clarify that?
08:22 danvet: or "* Last resort fallback for applying patches, in case all area expert committers are somehow unavailable"?
08:22 j4ni: okay
08:28 foofrag: is this place ok for newbie questions (about mesa code)?
08:29 danvet: sure
08:30 foofrag: so i wanted to know why opengl dri drivers ignore the return value from _mesa_make_current in their implementations of glXMake*Current?
08:32 danvet: git blame might know
08:34 foofrag: i tried that: so far i was able to grasp that _mesa_make_current at one point did not have return value; jfonseca added the return values in early 2009 and succesively used it one implementation (OSMesa); later that code got removed
08:37 foofrag: other drivers seem to have their code introduced much later (meaning, by then _mesa_make_current already have a return value), yet they ignore it
08:38 foofrag: git grep _mesa_make_current tells me that out of 30-odd calls, only 4 actually take the return value
08:44 foofrag: notice that _mesa_make_current can fail, returning false (GL_FALSE); it seems that, in general, drivers will ignore that potential failure and continue on, returning true, without necessarily recovering from the failure in _mesa_make_current
08:45 foofrag: that's how i discovered this
08:46 foofrag: i don't know if it's a feature or a bug
08:46 danvet: tbh I'm no mesa expert at all
08:46 danvet: and the context/current stuff is afaik known to be a bit fragile
08:47 danvet: if you have time, I'd suggest you try to fix up a driver you can test as an example
08:47 danvet: then submit it as an rfc to the mesa mailing list
08:47 danvet: asking whether that should be fixed or not or what is going on here
08:48 danvet: lots of mesa experts are asleep atm
08:48 foofrag: ok, i'll wait a bit more to see if someone here can answer, if not, i'll remember your suggestion, thanks!
11:47 kisak: tarceri: is the comment in https://lists.freedesktop.org/archives/mesa-dev/2017-March/149673.html describing the difference between the initial shader cache behavior and what will be the new behavior? Commenting on the difference doesn't make sense to me for a feature that's not in a point release yet (compared to just stating the intended behavior).
12:40 robclark: daniels, danvet, hmm, random thought.. if you have a compositor w/ an output loop thread for each of two (or more) displays, they could race each other between atomic test and commit.. ie. both of their test-only steps might have been on their own valid, but the first one to commit might make the 2nd's config no longer valid.. maybe we should have had a test-and-give-me-back-a-reserved-state-handle type thing.. unless you had some idea h
12:40 robclark: ow to handle that from userspace
12:40 daniels: robclark: also, it's been pointed out that i meant dependency('gbm', version: '>= 17.0')
12:40 robclark: (the good news is, I think, adding this sorta thing should be totally transparent to drivers)
12:41 robclark: ahh, k
12:41 daniels: robclark: i don't have any clever ideas, and you'd need to serialise on placing the state handle anyway
12:41 daniels: weston is relentlessly single-threaded
12:42 pq: robclark, "don't be stupid" comes to mind as a guide for userspace ;-)
12:42 robclark: hmm, I thought weston used to have an output loop per display to deal w/ different refresh rates
12:42 pq: robclark, it has a loop per output yes, but not threads. It's just state machines.
12:42 robclark: *ahh*
12:43 daniels: ^ it's all single-thread, purely event-driven
12:43 daniels: well, event and timer
12:43 robclark: well, I guess you could still have the same issue..
12:43 daniels: nope?
12:43 pq: robclark, not with daniels' design :-)
12:43 robclark: unless the state building for the test-only part was serialized
12:43 daniels: correct :)
12:43 robclark: *ahh*
12:43 daniels: we don't pre-empt between starting our assign_planes loop (where we batter TEST_ONLY), and committing
12:44 robclark: ok, that works
12:44 pq: however, if keithp et al. implement DRM resource splitting for VR/HMD purposes, I wonder if this will actually become a real problem
12:45 robclark: if you don't partition all the resources, incl driver internal resources, then yes I think it could be
12:45 robclark:bbl.. carpool time..
12:45 daniels: i'm also struggling to think how you'd use the reserved-handle thing; if you have two threads, and thread A has generated some state with TEST_ONLY whilst thread B wants to also test out some stage, B needs to validate against A's 'saved state', inasmuch as it exists. which means that when you need to commit B, you also have to commit A at the same time. so
12:45 daniels: you've kinda just coalesced your repaint loops into one :\
12:46 danvet: pq, that's why I want the split-out drm node to be tied to a specific master
12:47 danvet: with revoke support
12:48 pq: danvet, would you also be locking the video mode of the split-out part or somehow else guarantee that separate modesets on the different partitions cannot unexpectedly cause each other to fail (and to fail atomic TEST_ONLY semantics)?
12:53 danvet: I brought up a disable_modesets flag or so for those sub-nodes
12:53 danvet: but we might want to make them even more restrictive
12:53 danvet: since disabling modesets doesn't fix anything for shared plane resources
12:59 pq: yeah
13:01 pq: is all that just so that one does not need to write the plumbing to go through Xorg? I mean, I'm not yet completely bying the argument that you cannot go through the display server due to latency.
13:01 pq: or maybe Xorg actually makes it practically impossible to reliably go through the display server...
13:02 danvet: you want the X root to not include the hmd
13:02 pq: sure, but isn't that X's problem?
13:02 danvet: at that point you might as well write a small kernel patch to allow direct flipping
13:03 danvet: but it sounded a bit like keithp/airlied want that kernel patch to entirely avoid touching X
13:03 danvet: which I kinda don't like much
13:03 pq: small? :-)
13:03 danvet: "protocol too hard to work on"
13:03 danvet: pq, I assumed it'd be small, I didn't see it yet
13:04 pq: well, it sounds complicated to me, but I'm no kernel dev
13:04 vsyrjala: kwayland?
13:04 danvet: creating subnodes isn't hard
13:04 danvet: making sure they don't pull the main compositor over the table is
13:04 danvet: which is why imo that needs to be involved
13:04 danvet: and protocol
13:05 pq: danvet, I agree with you, FWIW
13:05 danvet: pq, but yeah the actual flip probably needs the special subnode
13:05 danvet: to have the lowest possible latency
13:05 danvet: you really want to get as close to vblank as possible with the final motion correction/prediction stuff for vr
13:06 pq: that's what people keep saying...
13:08 pq: do we have priority based GPU task scheduling with pre-emption yet? :-P
13:09 danvet: we're on it
13:09 pq: oooh, nice
13:09 danvet: both amd and i915 have that now, but no way yet to set priorities
13:09 danvet: but e.g. i915 auto-boost the compositor
13:10 pq: whoa
13:10 danvet: or well, whatever is blocking the flip
13:10 danvet: we could probably even wire up the boosting across dma_fence
13:10 danvet: for cross-driver boosting
13:11 danvet: but for that we'd need some shared sense of what a gpu priority means
13:11 pq: OTOH, why not manufacture machines with one connector labeled as "HMD", going straight to the discrete GPU which otherwise is not driving any outputs... nor running your desktop
13:13 vsyrjala: did anyone invent the input_event->compositor->client priority/performance boosting yet?
13:14 pq: vsyrjala, for which kind of input events?
13:14 vsyrjala: how many kinds do you have?
13:15 danvet: android essentially
13:15 danvet: they have a hack for the gpu scheduler
13:15 danvet: "oh, input event arrived, let's ramp the clocks up"
13:16 pq: oh, not in the context of VR?
13:16 danvet: just general ui responsiveness
13:16 danvet: the time it takes for userspace to mule over what to do could be used to jack up the gpu clocks
13:16 pq: I was thinking normal input vs. physical tracking which is an order of magnitude more Hz
13:17 pq: ahh
13:17 danvet: vr doesn't have idle periods, people can't hold still :-)
13:17 pq: indeed
13:18 daniels: danvet: yeah, i think the subnodes would pretty much need a drmModePageFlip-style 'steady-state' restriction, but the semantics of that get pretty awful pretty fast
13:18 danvet: daniels, I've heard padovan is working on async flips
13:19 danvet: we're probably looking at matching semantics
13:19 danvet: where maybe you're allowed to move the overlay
13:19 daniels: aye
13:19 danvet: but nothing else
13:19 danvet: nothing that might need to sync with anything else going on at least
13:20 daniels: i believe he's just looking at cursor updates indeed
13:20 daniels: danvet: also, there's EGL_IMG_context_priority which gives you a couple of priority levels per context, but it's not what you'd call state of the art
13:20 danvet: already told him to broaden scope a bit to include async page_flips in general
13:20 daniels: so that'll be two years then :P
13:20 danvet: I'm a bastard that way, I know
13:21 danvet: more seriously, just pointed him at all the async flip implementations we have
13:21 danvet: so that we can extract something that might actually work
13:21 danvet: the idea I tossed around is a async_check
13:22 danvet: which only takes the plane state (can't take crtc state, would sync)
13:22 danvet: and tells whether it works for async
13:22 danvet: plus an async_commit
13:22 danvet: then use those to implement cursors (if available) or async page_flips
13:22 danvet: or this vr thing
13:22 danvet: with a little neat helper that implements async_check for most drivers (with maybe a can_move flag)
13:23 danvet: similar to the plane scale check helper we have for real plane updates
13:23 danvet: and an async_commit helper that properly updates the plane_state (can't update the pointer or an ongoing modeset might get surprised)
13:24 danvet: not yet sure on the later thing
13:24 danvet: vr subnode could reuse this
13:24 danvet: page_flip, but only stuff that gets accepted by async_flip
13:27 daniels: yeah, that's going to be fun
13:54 hwentlan: danvet, i'll try to take a look today. looks like a big change
13:57 danvet: hwentlan, mostly mechanical
13:57 hwentlan: cool, i'll give it a shot. today shouldn't be too busy (i hope)
13:59 danvet: hwentlan, for more context we need to wire through the acquire ctx everywhere to allow drivers to have their own per-component locking
13:59 danvet: which I assume is something amdgpu would want
13:59 danvet: together with the infrastructure for private objs
14:00 danvet: abusing connection_mutex for everything shared gets old fast :-)
14:05 keithp: danvet: well, VR needs a separate compositor to make it useful; one that can deal with the IMU and keep the user from barfing when the app goes catatonic
14:07 danvet: keithp, it's the multiple compositors fighting each another
14:07 danvet: not that we need more than one
14:10 padovan: danvet: daniels: btw, I think that as a first step I'll focus more on async updates for cases where we don't have an update for the very same plane in the queued state. I think it will make things easier for now.
14:10 padovan: and it solves the cursor case at least
14:11 pq: keithp, oh, so there really are plans to have a separate (as in separate process) compositor from the actual games/apps?
14:17 danvet: bbrezillon, just stumbled over the tv stuff in drm_connector_state you've added
14:17 danvet: are the patches to start using this still stuck somewhere?
14:17 danvet:couldn't find anything
14:23 bbrezillon: danvet: I'm using it in the vc4 driver => https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/vc4/vc4_vec.c?id=refs/tags/v4.11-rc4#n345
14:31 keithp: pq: at this point, yes
14:31 keithp: there's a pile of transformation and color correction needed before presentation in any case
14:32 keithp: danvet: right, so we don't want them fighting, we want one to be in charge and then cede control over the HMD to the VR compositor
14:32 keithp: I'm trying to get a description of DRM mode object leasing written up, but that'll probably be later this week
14:34 danvet: bbrezillon, is that the only place?
14:34 danvet: this kinda looks funky
14:34 danvet: mlankhorst, ^^ pls cc bbrezillon on your locking fix for detect/fill_modes
14:35 danvet: bbrezillon, what I really wanted to ask though: if you change the tv mode property
14:35 danvet: does it correctly result in a modeset?
14:36 bbrezillon: yes, it did work
14:37 bbrezillon: and yes, this is the only place using these new fields
14:38 bbrezillon: danvet: what's the problem exactly?
14:39 danvet: you deref connector->state in get_modes
14:39 danvet: you don't hold the lock to do that
14:39 danvet: bbrezillon, for the modeset: are you sure?
14:39 danvet: you definitely don't go through the full state machinery to make it happen
14:39 danvet: full = both encoder and crtc
14:40 danvet: hm, not even that should happen ...
14:40 danvet:confused
14:41 danvet: bbrezillon, essentially nothing should be setting crtc_state->connectors_changed when you only touch the tv property
14:41 bbrezillon: well, I'm not sure I did it correctly, but it did change the TV mode
14:41 danvet: might be good to recheck
14:42 danvet: I just had a big discussion with mlankhorst how this kinda can't work
14:42 danvet: (doing tv props the atomic way in i915)
14:46 bbrezillon: hm, you mean ->atomic_check() and ->atomic_mode_set() won't be called because nothing changed on the connector side?
14:51 bbrezillon: danvet: I used modetest to test that, maybe that explains why I didn't face the problem you're describing
14:51 danvet: bbrezillon, could be
14:51 danvet: and encoder->atomic_check still should get called
14:51 danvet: but nothing else
14:52 danvet: and the design of setting connectors_changed from encoder->atomic_check doesn't really work
14:52 danvet: but that's roughly what I had in mind how it should work
14:52 danvet: mlankhorst is proposing a connectors->atomic_check just for setting connectors_changed and stuff like that
14:52 danvet: with more than 1 driver it'd be easier to figure out a good design
14:55 bbrezillon: hm, ok
14:56 bbrezillon: shouldn't connectors_changed be set by the core for things like TV mode?
15:08 danvet: bbrezillon, maybe?
15:08 danvet: there's definitely cases where we kinda don't want that
15:08 danvet: e.g. for some properties that you can change without a full modeset
15:09 bbrezillon: makes sense
15:31 tagr: danvet: yeah, sounds reasonable to me
15:57 Lyude: Hey, keep trying to get shader_runner to run this but it just exits immediately with "PIGLIT: {"result": "skip"}", does anyone have any idea why this might be? https://paste.fedoraproject.org/paste/LHRDScCe2Drk68cQNSDdAV5M1UNdIGYhyRLivL9gydE=
15:57 Lyude: (ignore the polygon mode thing, that's a feature for shader_runner on my branch that hasn't gotten merged just yet)
15:59 robclark: Lyude, wonder if GL_NV_fill_rectangle isn't exposed somehow?
16:00 Lyude: robclark: nah checked with glxinfo, it's definitely there
16:00 robclark: and this is running the shader_test under x11?
16:00 Lyude: a-ha, figured it out
16:00 mlankhorst: danvet: would definitely be nicer than the atomic encoder check
16:01 Lyude: The GLSL version requirement was before they actually added geometry shaders to opengl, so I guess shader_runner figured the best course of action was "silently ignore and exit"
16:03 mlankhorst: danvet: but could we explicitly clear best_encoder in the check?
16:04 danvet: mlankhorst, why do you want to clear best_encoder?
16:07 mlankhorst: danvet: might be out of date?
16:07 danvet: mlankhorst, my idea would be to call connnector->atomic_check before the mode_fixup loop
16:07 danvet: *before the add_affected_connectors before the mode_fixup loop
16:07 danvet: so best_encoder should be updated already
16:17 mlankhorst: ah k
16:17 mlankhorst: that's fine then
16:30 robher: robclark: this is android boot with your next-20170307-db410c-qcom-smmu-3-venus branch. Any ideas?: https://www.irccloud.com/pastebin/JyuctJLw/
16:39 robclark: robher, on db410c, I assume? Otherwise something very badly has gone wrong (ie. like wrong dtb)
16:44 robher: robclark: right.
16:45 robclark: hmm.. so I'd used that branch w/ android a week or two back..
16:45 robclark: possibly something config related.. I think this is what I was using: https://paste.fedoraproject.org/paste/4sRUzEPjBj9D3Qz2b~-F6F5M1UNdIGYhyRLivL9gydE=/
16:47 robclark: (is it possible to disable powerdomain stuff? not sure if somehow gpu isn't powered up..)
16:58 robher: robclark: not sure. I'm not seeing too many meaningful differences. I'm surprised your's booted android though. hwbinder is a requirement now and you don't have that enabled.
17:01 robclark: hmm, possible.. my last android userspace build was a few weeks back..
17:01 robclark: not sure how it would cause that sort of failure though..
17:05 robher: robclark: yeah, it would be later in the boot.
17:06 robher: robclark: with IOMMU enabled, do you care about the CMA size?
17:07 robclark: that WARN in qcom_iommu, I should probably look at (but on a different branch atm).. but that looks more like a badly handled cleanup path.. the timeout waiting to drain ringbuffer is the bigger problem..
17:07 robclark: naw, no use of CMA with iommu..
17:07 CosmicPenguin: robclark: MAX_CMDS == 4 - is this just a random value you picked or is there a history?
17:08 robclark: CosmicPenguin, it was a random(ish) picked value but that was removed a few kernel versions back..
17:08 robclark: with the "growable ringbuffer" thing I end up doing lots of cmds
17:09 robclark: there's even some great ascii art in the corresponding commit msg in libdrm..
17:09 robclark: https://cgit.freedesktop.org/mesa/drm/commit/freedreno?id=419a154dbef839b920689bea72aa9af41b2b114f
17:13 CosmicPenguin: ugh - suck it 4.4
17:14 robclark: oh, heh
17:14 CosmicPenguin: I should have checked
17:14 robclark: CosmicPenguin, well, iirc it should be a pretty easy thing to backport, I can track down the commit(s)..
17:14 CosmicPenguin: I'll find it
17:14 CosmicPenguin: I had it working on 4.9 and then went to 4.4 and was wtf?
17:15 robclark: iirc, the # 4 came from "context restore IB" (never really used) plus IB0 plus binning and draw IB1's
17:16 robclark: but turns it, it wasn't true the "4 ought to be enough for anyone" ;-)
17:16 CosmicPenguin: yeah, when you start tossing all the random buffers
17:17 CosmicPenguin: I have a replay of weston-simple-egl running with blob and it has 10! targets that need relocs
17:19 robclark: oh, yeah.. I guess blob also uses that whole CP_SET_DRAW_STATE thing which adds a bunch more..
17:26 imirkin_: Lyude: shader_runner picks whether to create a core or compat context based on the GLSL version requested
17:26 imirkin_: Lyude: geometry shaders are only a thing in #version 150
17:26 imirkin_: [or with various extensions that mesa doesn't implement, like ARB_geometry_shader4]
17:27 robher: robclark: well, I changed something and the crash is gone. either turning off other platforms or enabling more qcom drivers...
17:27 Lyude: imirkin_: ah
17:27 robclark: robher, the kconfig lottery :-(
17:28 robher: robclark: just need to automate booting make randconfig. ;)
17:30 robclark: heh, that has about a 0% chance of working.. lots of things don't work well when you are missing a clk driver, etc..
17:31 imirkin_: presumably certain things would be force-enabled for the board?
17:32 robher: robclark: I started with defconfig + android-*.config + kvm_guest.config BTW. Minimally the QCom IOMMU needs enabling in the defconfig.
17:33 robclark: hmm, default =y isn't enough? (Or did I make the default n ?)
17:33 robclark: imirkin, robher, I remember at one point someone was trying to make a dtb -> config type script, which would help a lot, imho
17:34 robher: robclark, imirkin_ : maybe we can call it scripts/dtc/dt_to_config. ;)
17:35 robclark: oh, that is already a thing?
17:35 robclark: nice
17:36 robher:should start using it...
18:20 robertfoss: zachr: I looked at the hwc2 series and rebasing the vsyncworker removal series ontop of it
18:20 robertfoss: zachr: and it all seems to work out
18:21 zachr: robertfoss, excellent news
18:21 robertfoss: zachr: however, the vsync related patch you NAKd in the hwc2 series is actually rather messy to remove.
18:22 robertfoss: zachr: It can still be removed, but the end result will be identical, and removing it will probably take 2 days
18:22 zachr: robertfoss, yeah, probably not worth your time to do that, so don't bother fixing the histroy.
18:23 robertfoss: zachr: perfect
18:23 robertfoss: zachr: Ill submit what I've got hten
19:49 mareko: FYI I plan to release new libdrm tomorrow