On Mon, Sep 02, 2019 at 09:12:22AM +0800, Jiaxun Yang wrote: > According to kernel policy[1] no more new FBDev driver would be accepted. > > Please refactor it to DRM. I obtained a functional DRM driver a while back, but unfortunately it's a poor fit on the hardware, for the following reasons, in brief: The DRM subsystem (in general) breaks user-space in significant ways: - fbset command timing mode settings are ignored; - attempts to set modes with /sys/class/graphics/fb0/mode are ignored; - /sys/class/graphics/fb0/modes outputs incorrect refresh rates; - relevant modes are missing in /sys/class/graphics/fb0/modes; - the standard DRM video modes seem to mix up the sync and front porch timings in struct drm_display_mode but this remains to be confirmed. DRM seems to rely heavily on EDID to negotiate a video resolution, but EDID isn't available with vintage analogue display hardware. The Graphics Synthesizer (GS) hardware is essentially a serial device that accepts sequences of commands with data via DMA. Notably, it cannot be memory mapped. Can the GS be modelled, in a reasonable way, on existing kernel video interfaces, when taking memory efficiency and performance into account? For anyone who is interested: In addition to this patch series and its documentation references, some background information and details on the Graphics Synthesizer are available here: https://github.com/frno7/linux/issues/10 Fredrik
