Platform=gles cursor issues

[vrazzer]

Was trying to get mouse input working with DRM/renderer=gles and ran into several cursor-support issues:

1- Mouse pointer input processing requires cursor display. This seems wrong. Would expect pointer devices always active with the cursor an optional display item. That is how wayland works where inputs are always passed to webkit and the compositor decides whether or not to display a cursor.

2- The cursor support code is very independent of the other DRM code to the point that duplicated state goes out of sync if the cursor code makes different display choices vs the DRM code. Am guessing the cursor support only works on platforms where the selected output device happens to use the first connector and first CRTC as returned via DRM resource enumeration. Am using a Pi4 with 3 CRTCs and it guesses wrong.

3- kms.c/kms_screen_probe will segfault if any of the connectors are disconnected. Unguarded memcpy of &con->modes[0] without NULL-check.

4- The cursorData mouse image did not scale properly from 48x48 to 16x16. Unclear what happened, but almost a secondary ghost image against a black background. Resampled the original 48x48 and it looks better, but some detail gets lost.

Seems like drm_data should be the source of truth for everything it contains (screen resolution, CRTC-id, etc) and struct cursor should supplement vs. duplicating. Hacking the cursor CRTC to match the drm_data CRTC plus fixing the enumeration crash and choosing a valid connector makes the cursor work on a Pi4. (Suspect several of these issues occur with renderer=drm on multi-CRTC devices, but cannot confirm.) Regardless, the cursor has been very helpful in experimenting with cog and appreciate it being there.

[aperezdc]

@vrazzer Indeed, I have seen issues with the cursor myself, and I agree with all the issues and the improvement proposal (processing input independent from displaying cursor) that you wrote.

[vrazzer]

If @kytart is around and wants to address some of these issues, can provide more detail. Currently running a hacked version that adds multiple cursors (pointer-cursor with hand-cursor over links) along with cursor show/hide under program control. Most of my app uses spatial navigation via remote control with the cursor hidden. When visiting an external web page, the cursor is displayed for easier navigation. I also changed the cursor bitmaps to parse from hand-editable text-strings rather than binary string-blobs.

[vrazzer]

While trying to get a context-menu working, found mouse button behavior was very odd. All three mouse buttons would activate a link, but left-button did it at mouse-down while the other two buttons did it at mouse up. Also, the right mouse button would never fire oncontextmenu. Finally, the event data from an onmousedown event was wrong-- event.which and event.button were always zero. The explanation was found in the wayland platform code pointer_on_button() function:

    /* @FIXME: what is this for?
    if (button >= BTN_MOUSE)
        button = button - BTN_MOUSE + 1;
    else
        button = 0;
    */

This is related to the comment in the keyboard handling: // Explanation for the offset-by-8, copied from Weston: // evdev XKB rules reflect X's broken keycode system, which starts at 8

wpe_view_backend_dispatch_pointer_event() expects mouse button events starting at 1 and thus the need to subtract (BTN_MOUSE-1). With that change, mouse events work mostly as expected. The caviat is that right-button (context-menu) seems to confuse webkit/cog. Guessing this is because no context-menu handler is present, but still investigating. (Oncontextmenu fires as expected, but the browser ends up in a weird state.)

Additional info: Adding a Javascript oncontextmenu that calls preventDefault() works reliably. Without preventDefault(), WebKit goes into a weird state when it gets the context menu request. I have both "context-menu" and "context-menu-dismissed" signals connected and neither ever fires.