a few problems i found on my rpi's...
1. rpi's retun that they do NO rotations (not even the normal 0 degree
default), so assume 0 degrees if none listed. this makes screen setup
even try and configure things on these kinds of drivers/devices
2. there was a mistmatch of 0, 90, 180, 270 srtyle rotation ints vs
the enum stype ecore drm2 uses. this fixes that so it uses ecore_drm2
considtently as ecore_drm2 expects. this stops output becomeing odd.
3. also seemingly we forgot to set the max mouse region based on res.
re-enable that commented out function.
now i can change res on my rpi3 and rpi4 in wl mode and it works right...
hooray!
EFL 1.23 changed API with regard to pointer device capabilities, so we
need to adjust API usage here based on efl version.
Original patch from bu5hm4n (Marcel Hollerbach)
Summary:
This patch refactors _drm2_randr_apply inside the wl_drm module in
order to support multiple outputs and to fix issue of rotation not
working
ref T7690
Reviewers: raster, cedric
Subscribers: cedric, zmike
Tags: #efl, #do_not_merge, #enlightenment-git
Maniphest Tasks: T7690
Differential Revision: https://phab.enlightenment.org/D8117
Reverting this as it has issues still, and when multi-output support
for wayland lands this is not going to work anyway.
This reverts commit 8f5299be08.
This change is needed because if we call
ecore_evas_screen_geometry_get before calling e_comp_wl_init, then
when the drm2 randr settings are applied, the screen geometry could
change (saved resolutions are restored). This commit ensures that drm2
has the same resolution settings as the randr ones, and
screen_geometry_get will return the proper values now.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch enables all degrees of rotation to be selectable in the
Screen Setup dialog. It then applies the rotation based on hardware or
software ... that is, if the hardware can do the selected rotation,
then we use hardware otherwise we will use ecore_evas_rotation
functions (software).
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we pass in screen geometry here when trying to set an output mode,
we can encounter "out of memory" errors from libdrm with outputs that
have a high resolution. As it turns out, we should be passing 0, 0 for
the x/y values when trying to set an output mode.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Small patch which adds the screen geometry to the output of drm2 randr
apply so we can test mutli-output setups and know which screen is where.
NB: No functional changes
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Previously when we were getting the output size, the resulting
geometry was being placed in the wrong variables which resulting in
randr screen config modes being set to zero. This patch also fixes the
issue where when setting drm2 output mode, we were always passing in
0x0 as the output geometry.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
for now i just added HAVE_WL_DRM but its just the same as
USE_MODULE_WL_DRM, maybe we can replace HAVE_WL_DRM once autotools is
gone, so we have a clear pattern.
a reason for doing that is that you can just pack together targets into
a array and pass them to our helper, and the helper will just handle
them, so even module with eldbus codegen etc is now supported.
This also means that we are just passing the src object directly into
the shared_module call, which means the user of our helper can just pack
everything he needs into the src var and the helper does not need to
know about it.
It appears that config.geom.x and config.geom.y specify the corner of
an output in global space, but ecore_drm2_output_mode_set's x and y
are offsets into the framebuffer for the corner of the display.
Just pass 0, 0 and everything will be ok.
I missed this in my last commit - we probably shouldn't be calling
e_comp_render_queue or e_comp_shape_queue_block() after hiding the
ecore_evas anyway - and by removing the e_comp_shape_queue_block()
in the activation callback I made things asymmetrical. Ungood.
The code intended to force evas to redraw when we switch back from
another virtual console is failing to do so. Remove it and replace
it with simpler code that successfully forces a redraw.