13:45pcercuei: On my hardware, the crtc needs to be disabled in order to change the overlay plane's bpp, position or size
13:45pcercuei: What would be the best way to handle this?
14:23agd5f: mripard, thanks for the backmerge
14:24agd5f: mripard, I'm seeing tons of ./include/linux/signal.h:27:5: error: conflicting types for ‘copy_siginfo_to_user’
14:24agd5f: haven't had breakfast or coffee yet
14:29agd5f: looks like b9253a43370e8f3c46c0ee24b04fa2ffec37b7c0 was mis-merged or something
14:30mripard: agd5f: on drm-misc-next-fixes ?
14:30mripard: I'm recompiling to test, but I've not seen one so far
14:30mripard: which defconfig / compiler do you use ?
14:32mripard: yeah, drm-misc-arm64_defconfig compiles without a warning here on gcc10 (aside from strcpy one) with gcc10.1
14:34agd5f: looks like include/asm-generic/siginfo.h was removed in 6bc51cbaa9d75c7c240282da5ff270815caccac0
14:36agd5f: weird. I guess my tree had a stale copy. I swear I cleaned it
14:36agd5f: seems to be fix. sorry for the noise
16:47pcercuei: How can I make sure that my crtc is disabled when my plane's atomic_update callback is called?
17:01imirkin: pcercuei: not 100% sure, but sounds like you need a full modeset to perform those operations
17:01imirkin: i believe there's some way to signal to userspace that certain changes require a full modeset
17:03imirkin: [please use this as a temporary answer until someone like robclark airlied or danvet can respond]
17:05danvet: pcercuei, so if in your atomic_check function you realize some state change needs a full disable/enable cycle
17:06danvet: then you can indicate this by various state bits that feed into drm_atomic_crtc_needs_modeset()
17:06robclark: I think the answer is atomic_check rejects the change if full modeset is needed and the ALLOW_MODESET flag is not set
17:06danvet: kerneldoc for that stuff is pretty good
17:07danvet: and as robclark just said, once you set that the atomic core will correctly reject an atomic update if userspace isn't ok with that full modeset
17:07danvet: pcercuei, the other bit is about ordering, you might want to look into overwriting the atomic_tail function
17:07danvet: again should be pretty well documented in kerneldoc why you might need that
17:07danvet: plus reading other drivers gives you ideas
17:09danvet: pcercuei, drm_atomic_helper_commit_tail_rpm probably what you want
17:09danvet: or maybe not
17:16pcercuei: isn't drm_atomic_helper_commit_tail_rpm the opposite of what I want?
17:16pcercuei: It says "for drivers that [...] need the CRTC to be enabled to perform a commit"
17:26pcercuei: robclark: if the change is rejected, how does userspace know that it should try again with the crtc disabled?
17:27robclark: it kinda doesn't.. otoh, if userspace didn't might the screen going off and back it could have set ALLOW_MODESET in the first place
17:28robclark: generally that isn't going to be something userspace wants, I don't think
18:21pcercuei: alright, setting "crtc_state->mode_changed = 1" in my plane_atomic_check() did the trick
18:21pcercuei: thanks for the help
19:10pcercuei: Another problem :)
19:11pcercuei: I'm testing my planes with modetest, and it seems to be working correctly
19:12pcercuei: When I Ctrl-C the modetest program, it calls my plane_atomic_disable() on each plane, which means I'm not getting a EOF IRQ, so the DRM core complains about a missed vblank
19:12pcercuei: I believe I can make it so that the primary plane can never be disabled, but I don't know if that's the way to go
19:40airlied: danvet: hey when i run dim update-branches recently, I'm seeing a lot of error: refs/tags/drm-misc-fixes-2018-05-30 does not point to a valid object!
19:40airlied: for quite a lot of misc-fixes tags
19:40airlied: oh and intel-fixes tags
19:41airlied: is it just me? maybe I got local corruption somewhere
19:42danvet: seems to work on the server
19:42danvet: and here too
19:42danvet: I think time to wave goodbye to that fs?
19:42airlied: okay I probably just had some tree do something silly
19:42airlied: fsck time
20:05daniels: if you use a shared git object tree, then gc can eat your objects
20:07imirkin: there's a semi-new thing called "git worktree" which solves this
20:08imirkin: it's a lot more reliable than the old "git-newworkdir" or whatever it was called
20:08imirkin: since it centrally keeps track of all the work trees and ensures that the checked out things don't get GC'd