Re: [PATCH v3 26/32] drm/via: Add via_drm.h

[Kevin Brace <kevinbrace@gmx.com>]

Hi Sam,

Regarding DRI1 era uAPI, I believe I am handling the matter similar to how Radeon DRM header (include/uapi/drm/radeon_drm.h) handled the matter.
The header still contains old DRI1 uAPI calls, and it then adds new KMS generation uAPI calls.
At this point, using drm_invalid_op() for OpenChrome DRM is the least intrusive option, and that's the way I will like to keep it.
It is just that I did not know its existence, so it was not in the code.
The older OpenChrome DDX releases might assume uAPI backward compatibility, but the use of drm_invalid_op() should gracefully tell the DDX that the legacy DRI1 VIA DRM uAPI is no longer supported.
    Personally, I do not anticipate Wayland use with OpenChrome.
It will end up living out its life as X.Org X Server only solution considering its hardware age.
Although it is somewhat hard, I use Gentoo Linux as development platform for OpenChrome, and 32-bit x86 ISA and X.Org X Server are still fully supported.

Regards,

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


> Sent: Tuesday, August 02, 2022 at 4:09 AM
> From: "Sam Ravnborg" <sam@ravnborg.org>
> To: "Kevin Brace" <kevinbrace@gmx.com>
> Cc: "Thomas Zimmermann" <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h
>
> Hi Kevin,
> >
> > OpenChrome DDX carries lots of legacy code.
> >
> > https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/tree/src/via_drm.h?h=main&id=dc661c59257e855cd9b29c14b91a8ee2d9b86ccb
> >
> > There is a requirement to use the same via_drm.h with both DDX and DRM.
> > Hence, I need to keep a lot of the legacy DRI1 definitions inside via_drm.h.
>
> This part is fully understood. Also on top of this the via DRI1 driver
> uses this. I am not asking to have anything deleted from the existing
> uapi via_drm.h file.
>
>
> My feedback is that the following code should be dropped from the
> openchrome driver:
>
> +	DRM_IOCTL_DEF_DRV(VIA_ALLOCMEM, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_FREEMEM, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_AGP_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER),
> +	DRM_IOCTL_DEF_DRV(VIA_FB_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER),
> +	DRM_IOCTL_DEF_DRV(VIA_MAP_INIT, drm_invalid_op, DRM_AUTH | DRM_MASTER),
> +	DRM_IOCTL_DEF_DRV(VIA_DEC_FUTEX, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_DMA_INIT, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_CMDBUFFER, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_FLUSH, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_PCICMD, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_CMDBUF_SIZE, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_WAIT_IRQ, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_DMA_BLIT, drm_invalid_op, DRM_AUTH),
> +	DRM_IOCTL_DEF_DRV(VIA_BLIT_SYNC, drm_invalid_op, DRM_AUTH),
>
> (Copied from openchrome-drm - I recall you did not post this code yet).
>
> The new openchrome driver should not care at all about the old UAPI,
> so just drop the above.
>
> The comment above is based on the understanding that when we have a kms
> compliant driver the user space is generic and we do not expect or need
> any via specifics in user space.
>
> In other words - x86-video-openchrome should - according to my
> understanding - not be needed. And we can have a fully operational
> wayland (and maybe X) userspace using the generic UAPI. This is where
> Thomas Zimmermann's comment about dumb buffers are relevant.
>
> Do I miss something obvious here?
>
> 	Sam
>