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