Hi
Am 26.03.19 um 17:03 schrieb Adam Jackson:
On Tue, 2019-03-26 at 10:17 +0100, Thomas Zimmermann wrote:
+static bool is_generic_driver(const struct fb_info *fb_info) +{
- /* DRM porting note: We don't want to bind to vga16fb, vesafb, or any
* other generic fbdev driver. Usually, these drivers have limited* capabilitis. We only continue if the fix structure indicates a* hardware-specific drivers . This test will also sort out drivers* registered via DRM's fbdev emulation. If you're porting an fbdev* driver to DRM, you can remove this test. The module's PCI device* ids will contain this information.*/- return !fb_info->fix.accel &&
!!strcmp(fb_info->fix.id, "S3 Virge/DX");+}
This seems odd. s3fb sets fix.accel to NULL unconditionally AFAICT, not sure why you're testing for that explicitly.
If accel is 0, it might be a generic driver. Hence, fbdevdrm ignored s3fb, so I added the exception.
I do have a question though: why _not_ support generic fbdev drivers? If I had that, and the ability to disable creation of /dev/fb*, I could expose a consistent video device enumeration to userspace. As it stands I have no reasonable way of knowing which fbdev and drm devices are pointed at the same hardware. If there were only drm devices...
Ignoring generic drivers seemed like the safe bet for now. I found that vga16fb, vesafb, etc bind to hardware and later get replaced by HW-specific drivers; DRM drivers with FB emulation should not be handled by fbdevdrm. So for now, fbdevdrm ignores all this.
This all comes from using the event-reporting mechanism to hook into the fbdev module. Daniel suggested to copy over some of the fbdev drivers for porting, which would solve the problem.
Best regards Thomas
- ajax