Re: [PATCH 02/11] drm/fbdevdrm: Add fbdevdrm device

From: Thomas Zimmermann <tzimmermann@suse.de>
To: Adam Jackson <ajax@redhat.com>,
	airlied@linux.ie, daniel@ffwll.ch, b.zolnierkie@samsung.com
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 02/11] drm/fbdevdrm: Add fbdevdrm device
Date: Wed, 27 Mar 2019 07:55:03 +0000	[thread overview]
Message-ID: <a0697626-dc39-702e-3850-def8cbc71508@suse.de> (raw)
In-Reply-To: <0d2e7dccd35523dd652a3d4af4b031f8d9ab8efd.camel@redhat.com>

[-- Attachment #1.1: Type: text/plain, Size: 2077 bytes --]

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
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]