From: Sam Ravnborg <sam@ravnborg.org>
To: Kevin Brace <kevinbrace@gmx.com>
Cc: dri-devel@lists.freedesktop.org, Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH v3 26/32] drm/via: Add via_drm.h
Date: Tue, 2 Aug 2022 13:09:34 +0200 [thread overview]
Message-ID: <YukF7guP0EBIz0PT@ravnborg.org> (raw)
In-Reply-To: <trinity-4501b716-d008-4a86-9e0c-681c301e4b87-1659399030120@3c-app-mailcom-bs06>
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
next prev parent reply other threads:[~2022-08-02 11:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 23:53 [PATCH v3 20/32] drm/via: Add via_pll.c Kevin Brace
2022-07-25 23:53 ` [PATCH v3 21/32] drm/via: Add via_pm.c Kevin Brace
2022-07-25 23:53 ` [PATCH v3 22/32] drm/via: Add via_sii164.c Kevin Brace
2022-07-25 23:53 ` [PATCH v3 23/32] drm/via: Add via_tmds.c Kevin Brace
2022-07-25 23:53 ` [PATCH v3 24/32] drm/via: Add via_ttm.c Kevin Brace
2022-07-25 23:53 ` [PATCH v3 25/32] drm/via: Add via_vt1632.c Kevin Brace
2022-07-25 23:53 ` [PATCH v3 26/32] drm/via: Add via_drm.h Kevin Brace
2022-07-26 17:41 ` Sam Ravnborg
2022-07-26 18:18 ` Thomas Zimmermann
2022-07-26 20:20 ` Dave Airlie
2022-07-27 7:36 ` Thomas Zimmermann
2022-07-29 1:06 ` Kevin Brace
2022-07-31 2:14 ` Kevin Brace
2022-07-26 18:24 ` Thomas Zimmermann
2022-07-30 22:48 ` Kevin Brace
2022-08-01 14:40 ` Sam Ravnborg
2022-08-02 0:10 ` Kevin Brace
2022-08-02 11:09 ` Sam Ravnborg [this message]
2022-08-02 18:12 ` Kevin Brace
2022-08-01 18:49 ` Thomas Zimmermann
2022-08-02 3:45 ` Kevin Brace
2022-08-02 11:38 ` Thomas Zimmermann
2022-08-03 1:49 ` Kevin Brace
2022-08-04 12:20 ` Thomas Zimmermann
2022-08-04 15:09 ` Sam Ravnborg
2022-07-25 23:53 ` [PATCH v3 27/32] drm/via: Add new VIA Technologies Chrome supporting PCI IDs to DRM Kevin Brace
2022-07-25 23:53 ` [PATCH v3 28/32] drm/via: Zero out chip type field Kevin Brace
2022-07-25 23:53 ` [PATCH v3 29/32] drm/via: Add new VIA Technologies PCI device IDs related to graphics Kevin Brace
2022-07-25 23:53 ` [PATCH v3 30/32] drm/via: Add Kconfig Kevin Brace
2022-07-26 7:28 ` Thomas Zimmermann
2022-07-31 1:49 ` Kevin Brace
2022-08-01 10:36 ` Thomas Zimmermann
2022-07-25 23:53 ` [PATCH v3 31/32] drm/via: Add Makefile Kevin Brace
2022-07-26 7:29 ` Thomas Zimmermann
2022-07-31 1:55 ` Kevin Brace
2022-07-25 23:53 ` [PATCH v3 32/32] drm/via: Modify DRM core to be able to build OpenChrome DRM Kevin Brace
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YukF7guP0EBIz0PT@ravnborg.org \
--to=sam@ravnborg.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kevinbrace@gmx.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).