Amlogic: handle persistent DRM hotplug events on the main thread

[manuandre]

Description

Keep the Amlogic DRM udev monitor active across hotplug events and defer
hotplug processing to the window-system message pump.

The udev callback now only records a pending hotplug event. MessagePump(),
which runs on Kodi's main process thread, consumes that state and calls
HotplugEvent().

The monitor cleanup path is also made safe and idempotent.

Motivation and context

The DRM hotplug monitor was stopped from inside its own event callback and
HotplugEvent() was processed directly on the event-monitor worker thread.

This had two problems:

• stopping the monitor from its callback could re-enter the event monitor
  locking path;
• the monitor became effectively one-shot, so subsequent HDMI hotplug events
  were no longer reliably handled.

Keeping the monitor persistent and dispatching the actual hotplug work through
the existing window-system message pump avoids both issues.

How has this been tested?

Ugoos AM6B Plus (S922X), CoreELEC 22, built as a complete Amlogic image with
this change applied.

Repeated HDMI disconnect/reconnect cycles were tested.

The runtime log confirmed:

• the udev callback runs on the event-monitor worker thread;
• HotplugEvent() runs on Kodi's main process thread;
• the monitor continues receiving events over multiple hotplug cycles;
• the DRM connector transitions through the temporary one-mode state and
  recovers the normal display modes after reconnect;
• the same Kodi process remained active throughout, with no crash or restart.

What is the effect on users?

HDMI hotplug events on Amlogic remain monitored after the first event and the
resulting DRM/display handling is performed on Kodi's main thread.

Types of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the Code Guidelines of this project
• I have read the Contributing document
• I have added tests to cover my change

[Portisch]

1. When booting now without HDMI connected and waiting until Kodi is started screen remain black.
   The MessagePump function is not called anymore.

2. sc mask kodi, disconnect HDMI and reboot.
   Wait until booted and then: sc unmask kodi, sc start kodi. Oops do happen: kodi.bin[1080]: unhandled exception: DABT (lower EL), ESR 0x0000000092000006, level 2 translation fault.
   This I guess happen now because of the call udev_monitor_unref.

[manuandre]

Thanks, I reproduced and investigated both cases.
For the first one, the reason MessagePump() was no longer called was that Kodi's main thread could block indefinitely in libMali inside eglSwapBuffers() when booting without HDMI. I added a guard in PresentRender() to skip presentation while the cached DRM connector is disconnected or a hotplug event is pending.
With the current branch I tested:
boot with HDMI disconnected;
Kodi reaches Running the application;
reconnect HDMI;
the persistent udev monitor receives the hotplug events;
HotplugEvent() is processed on the Kodi main thread;
the connector eventually becomes ready and the picture comes back;
Kodi stays in the same process, with no restart.
I also repeated your second scenario with Kodi prevented from starting during boot, HDMI disconnected, then starting Kodi manually afterwards. I could not reproduce the DABT with the current branch. Kodi remained active/running, NRestarts=0, and there was no DABT, translation fault or kodi.bin exception in the kernel log.
So at this point I don't have evidence that udev_monitor_unref() is responsible for the DABT.
Separately, during one of the HPD/EDID negotiation sequences I did see a kernel warning:
BUG: sleeping function called from invalid context
coming from the amhdmitx workqueue (hdmitx_hpd_plugin_irq_handler → resman_notify_error_info()), but Kodi did not crash and HDMI eventually recovered normally.
I rebased the PR on the current aml-5.15.196-22.0 and pushed the tested changes.
By the way, do you have a standard test procedure or checklist you usually run for Amlogic/Kodi changes before considering a PR ready? If so, I’d be happy to run the same set of tests on this branch before considering it done.

[Portisch]

A PR is ready when it's functionality is confirmed.

Case 1. still doesn't work: PresentRender aml_get_display_connected: true, IsHotplugPending: false
Because of the forced mode switch the device is forced to be connected and MessagePump exit again.

[manuandre]

Thanks.
I reproduced your cases again on the current aml-5.15.196-22.0 base and found one remaining issue in case 1.
During HDMI reconnect, drmModeGetConnector() initially returned 25 modes but encoder_id == 0, so the cached m_connection remained disconnected. The hotplug recovery modeset itself succeeded, and a fresh DRM query afterwards showed the connector as connected with an encoder assigned, but Kodi was still using the stale connection state. This prevented presentation from being re-enabled.
I changed the hotplug recovery path to refresh the connector state from DRM after a successful atomic modeset. It does not force the connector to connected: the state comes from a new drmModeGetConnector() result after the modeset.
Retested:
Case 1
boot with HDMI disconnected;
Kodi reaches Running the application using dummy_l;
reconnect HDMI;
hotplug is processed on Kodi's main thread;
25 modes are detected;
forced modeset completes and the GBM surface is recreated;
Kodi Home becomes visible again;
same Kodi PID throughout, no restart.
Case 2
boot with Kodi masked and HDMI disconnected;
unmask/start Kodi manually;
Kodi reaches Running the application using dummy_l;
no DABT, translation fault or kodi.bin exception;
reconnect HDMI;
display recovers to Kodi Home with the same Kodi PID.
PR head is now 229dceb.