This patch modifies the ecore_evas animator ticking code for drm in
order to support ticks on a per-output basis
Depends on D6137
I think there's a 1:1 relationship between "tick" and "output" so it seems like there should be a way to get around ever having to do a list search for the tick stuff.
I suppose setting a user data pointer for an Ecore_Drm2_Output is one way (though perhaps not the best way)
This fixme seems to indicate that this code will crash on GL engines? Would like to see that fixed before landing.
I'm not sure I'm following this correctly - is this function now just setting the "primary" output to match canvas rotation, but leaving all other outputs in their current orientation?
I don't think this works for all output ordering?
O<O ^ O>O
the geometry would be one screen wider than it should?
Hmm, feels like this is going to bite us at some point. But I guess it's a reasonable stop-gap for the short term.
Is there a long term plan for handling mixed DPI multi-monitor setups?
Hmm I think for some graphics drivers this has the potential to fall apart hard, since each blanktime_get could end up waiting for a head to blank.
I *think* it might be safest to just use the first output's blank_time_get for all tick jobs - or just disable the tick job code entirely if there are multiple outputs enabled (but that can potentially hurt performance a little bit at start of tick too)
I think these params will all throw unused variable errors if BUILD_ECORE_EVAS_GL_DRM is unset?
I'd prefer to see this sort of purely cosmetic change that doesn't touch any code related to the functional change in this patch in another patch.
This is correct because edata came from a calloc, but I'd rather see this as a different patch as it's not a related change.
This is a nice refactor, but it would be easier to review in a separate patch
why is this commented out here?
Yea, this was just a note I left myself
I've no plan Yet .. but yes, the same thought crossed my mind at the time too
Ahh yes, good catch. WIll fix in the next patchset.
Sure, no problem
Ok, duly noted
Well, if you have 2 side-by-side monitors and try to pointer warp to the middle ... theoretically your mouse pointer could end up being drawn half on one and half on another. Really tho, this was just commented out (for the moment) because I was not going to deal with that problem in this patchset ... was more just looking at "getting this darn thing to work" ;)
question regarding this: Is an output's blank time variable ? or consistent between vblanks ? Asking because if it's consistent than we could store those values into the Output structure (after the first vblank) and inside output_blanktime_get check & return them if already set ... thus avoiding the potential of waiting for a head to blank.,...
I don't think using the first output's blank_time_get for all ticks is valid as the blank_time may be different between 2 different outputs ... and I don't want to disable tick_job code entirely either :(