10:53 <raster> daniels: btw... it seems the odroid go is abothr device with nasty EBUSY's on drmModeAtomicCommit()

10:53 <raster> we end up with retry loops which isnt nice... shouldnt this just not happen unless there is an actual error like disconnected/off display or something?

10:55 <daniels> I've never seen that on Rockchip and we've used that in a _lot_ of places ... usually EBUSY is 'too soon, you tried to touch this CRTC before the last one completed'

10:56 <raster> it doesn't just queue it?

10:57 <raster> or well.. shouldn't it?

10:57 <daniels> nope - if you do a drmModePageFlip, you have to wait until you get the completion event before you can do another - same with drmModeAtomicCommit, if you do one then you have to wait until you get the event back for that CRTC (it can deliver for multiple CRTCs) before you try to repaint again on that CRTC

10:57 <raster> hmmm

10:57 <raster> i'll poke in on that

10:57 <daniels> adding a queue rapidly devolves into how deep should the FIFO be, when should they be presented, how do you cancel, etc ...

11:03 <raster> damn this lcd panel barfing is annoying

11:05 <raster> hmm

11:05 <raster> odd

11:05 <raster> thats is what we do

11:06 <raster> if (edata->ticking && !ecore_drm2_output_pending_get(edata->output))

11:06 <raster> ecore_drm2_fb_flip(NULL, edata->output);

11:06 <raster> the pending get tells us if we have a pending flip with no completion yet

11:06 <raster> unless we messed tracking of that up..

11:11 <raster> we set up drmEventContext's page_flip_handler that's used to handle the completion...

11:24 <raster> aaaah it's one of our flip timeouts

11:26 <raster> that forces us to retry a flip after we timed out from a prior flip for 50ms.

11:38 <raster> yup. our timeout is too agressive...

11:38 <raster> i'm pretty sure i put that in to work around other problems like i think it was on intel where a flip would never complete ....

11:40 <daniels> heh, right

11:40 <raster> i guess glmark workload was somehow causing a stall that put us over the edge...

11:41 <raster> but i do know we got this deadlock onintel where sometimes it'djust stop rendering... like mainloop was fine

11:41 <raster> just nada . no new frames. i tracked it dow to submitting an atomic flip but never gettting a completion, so i added a timeout - decided 50ms was "good enough" and added a retry that somehow unstuck things ...

11:41 <raster> but now thats proving a problem elsewhere... grrrr

11:43 <raster> well glmark happily runs until it segfaults without some nasty atomic flip complaints now

11:43 <raster> i think my quick and dirty change to 2 seconds of timeout does the trick :)

12:40 <daniels> nice!

13:17 <raster> daniels: did you ever encoutner intl devices that do this? (flip but no complete) ?

15:32 <daniels> raster: err nope ... well apart from gma500 but that's not exactly intel :P

15:33 <daniels> we did add a watchdog which just aborts hard if we don't get a flip completion event within 5sec, but I've never got a bug report about that being triggered apart from on very weird downstream vendor hacked BSPs or under savage system load

16:21 <macc24> is gles3 enabled by defauly in mesa 20.2?

17:04 <raster> daniels: oh gma500...

17:04 <raster> stop swearing! :)

17:04 <raster> :)

17:05 <raster> daniels: hmm well i k now i added the workaround because of this. dialled it back now and no more flip ebusy complaints

17:05 <raster> i've set it at 1second but mainloop keeps running/working