[PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

Dave Airlie airlied at gmail.com
Mon Jun 12 07:27:14 UTC 2017


On 12 June 2017 at 16:56, Hans de Goede <hdegoede at redhat.com> wrote:
> This commit adds the vboxvideo drm/kms driver for the virtual graphics
> card used in Virtual Box virtual machines to drivers/staging.
>
> Why drivers/staging? This driver is already being patched into the kernel
> by several distros, thus it is good to get this driver upstream soon, so
> that work on the driver can be easily shared.
>
> At the same time we want to take our time to get this driver properly
> cleaned up before submitting it as a normal driver under drivers/gpu/drm,
> putting this driver in staging for now allows both.
>
> Note this driver has already been significantly cleaned up, when I started
> working on this the files under /usr/src/vboxguest/vboxvideo as installed
> by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681
> lines. The version in this commit has 7275 lines.
>
> Of those 7275 lines 3980 lines are in an osindependent directory which
> contains portable code which is shared with other guest platforms such as
> C-structure definitions for the virtual graphics card protocol and helper
> functions for using these structures to communicate with the card. Since
> these files are shared they are in the standard Virtual Box upstream code
> style and not in the kernel coding style. All files outside of the
> osindependent directory fully adhere to the kernel coding style.
>

Just some questions,

Does the hw have acceleration support of some kind? this driver seems
be a modesetting only one, which is fine, just wondering if there are
plans to do more.

We haven't used staging for drm drivers for a short while for a few
reasons, the speed of iterating the kms APIs esp in the atomic area
means nobody remembers to build staging, then you end up with broken
staging, I'd like to wait for Daniel to get back from holidays to
consult on whether we should just put this in non-staging so we don't
lose it down the cracks.

The most important thing is for the driver to be atomic if it's KMS
only, and it would be good to have someone review that properly.

Dave.


More information about the dri-devel mailing list