Hi,
On 12-06-17 09:27, Dave Airlie wrote:
On 12 June 2017 at 16:56, Hans de Goede <hdegoede@xxxxxxxxxx> 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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
