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

[Hans de Goede]

Hi,

On 12-06-17 09:27, Dave Airlie wrote:
> 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.

Michael, can you answer this. How does the 3D accel stuff for vbox work?
Is that supported under Linux guests at all  ?

> 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.

Ok.

> 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.

I believe it does not use the atomic APIs atm, so that would be one
of the first things to fix then. Another question is if people
(you and Daniel at least) can live with the non kernel-coding
style shared files under the osindependent dir ?

Regards,

Hans