Hi,
On 14-06-17 15:40, Michael Thayer wrote:
Hello Hans,
14.06.2017 15:30, Hans de Goede wrote:
[Discussion of vboxvideo and vboxguest driver clean-up.]
As I already mentioned in previous mails on this, for the vboxguest driver
my plan is to simply do a fork and remove anything related to the
14.06.2017 16:42, Sean Paul wrote:
[Discussion of vboxvideo driver kernel integration and clean-up.]
> Once the code is upstream, it's going to be difficult to motivate developers
> to
> keep the driver close to your downstream version. If I'm working on feature X
> which touches your driver, I'm
On Wed, Jun 14, 2017 at 11:34:10AM +0200, Michael Thayer wrote:
> Hello Sean,
>
> 13.06.2017 20:03, Sean Paul wrote:
> [Discussion of vboxvideo driver clean-up.]
>
> > First, thank you for your submission.
>
> Thank you for your feedback.
>
> [Discussion of the OS-independent code in the
Hello Hans,
14.06.2017 15:30, Hans de Goede wrote:
[Discussion of vboxvideo and vboxguest driver clean-up.]
> As I already mentioned in previous mails on this, for the vboxguest driver
> my plan is to simply do a fork and remove anything related to the
> portability. It currently weighs in at
Hi all,
On 14-06-17 11:34, Michael Thayer wrote:
Hello Sean,
13.06.2017 20:03, Sean Paul wrote:
[Discussion of vboxvideo driver clean-up.]
First, thank you for your submission.
Thank you for your feedback.
[Discussion of the OS-independent code in the driver submission.]
I took a quick
Hello Sean,
13.06.2017 20:03, Sean Paul wrote:
[Discussion of vboxvideo driver clean-up.]
> First, thank you for your submission.
Thank you for your feedback.
[Discussion of the OS-independent code in the driver submission.]
> I took a quick skim through your driver, and there doesn't seem to
13.06.2017 17:41, Greg Kroah-Hartman wrote:
[...]
> And why is the closed vbox-devel list still on the cc: here, the bounces
> from it are getting annoying.
[...]
Not sure why you are still getting them, but we added you to the
white-list as well. I would prefer the list to stay on as the
On Tue, Jun 13, 2017 at 01:50:16PM +0200, Michael Thayer wrote:
> 12.06.2017 18:03, Greg Kroah-Hartman wrote:
> > On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 12-06-17 13:44, Greg Kroah-Hartman wrote:
> >>> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de
On Tue, Jun 13, 2017 at 05:00:15PM +0200, Michael Thayer wrote:
> 13.06.2017 15:59, Greg Kroah-Hartman wrote:
> > On Tue, Jun 13, 2017 at 03:45:14PM +0200, Michael Thayer wrote:
> >> 13.06.2017 14:48, Greg Kroah-Hartman wrote:
> >> [Discussion of vboxvideo coding style.]
> >>> Once your code is
13.06.2017 15:59, Greg Kroah-Hartman wrote:
> On Tue, Jun 13, 2017 at 03:45:14PM +0200, Michael Thayer wrote:
>> 13.06.2017 14:48, Greg Kroah-Hartman wrote:
>> [Discussion of vboxvideo coding style.]
>>> Once your code is accepted into the main kernel tree, why would you
>>> continue to work in an
On Tue, Jun 13, 2017 at 03:45:14PM +0200, Michael Thayer wrote:
> 13.06.2017 14:48, Greg Kroah-Hartman wrote:
> [Discussion of vboxvideo coding style.]
> > Once your code is accepted into the main kernel tree, why would you
> > continue to work in an out-of-tree repo anyway? That's ripe for
> >
13.06.2017 14:48, Greg Kroah-Hartman wrote:
[Discussion of vboxvideo coding style.]
> Once your code is accepted into the main kernel tree, why would you
> continue to work in an out-of-tree repo anyway? That's ripe for
> disaster, what's keeping you from just working with the in-tree version?
On Tue, Jun 13, 2017 at 01:50:16PM +0200, Michael Thayer wrote:
> 12.06.2017 18:03, Greg Kroah-Hartman wrote:
> > On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 12-06-17 13:44, Greg Kroah-Hartman wrote:
> >>> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de
12.06.2017 18:03, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 12-06-17 13:44, Greg Kroah-Hartman wrote:
>>> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
> The most important thing is for the driver to be atomic if
Hi,
On 12-06-17 18:03, Greg Kroah-Hartman wrote:
On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote:
Hi,
On 12-06-17 13:44, Greg Kroah-Hartman wrote:
On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
The most important thing is for the driver to be atomic if it's KMS
On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote:
> Hi,
>
> On 12-06-17 13:44, Greg Kroah-Hartman wrote:
> > On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
> > > > The most important thing is for the driver to be atomic if it's KMS
> > > > only, and it would be good
Hi,
On 12-06-17 13:44, Greg Kroah-Hartman wrote:
On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
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,
On Mon, Jun 12, 2017 at 02:46:54PM +0200, Michael Thayer wrote:
> Hello Greg,
>
> 12.06.2017 13:47, Greg Kroah-Hartman wrote:
> > On Mon, Jun 12, 2017 at 01:44:09PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
> > > > > The most important
Hello Greg,
12.06.2017 13:47, Greg Kroah-Hartman wrote:
On Mon, Jun 12, 2017 at 01:44:09PM +0200, Greg Kroah-Hartman wrote:
On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
The most important thing is for the driver to be atomic if it's KMS
only, and it would be good to have
It's going to be basically impossible to keep the out of tree in sync
with the staging version because there are so many changes needed
everywhere.
Generally in the kernel we don't care about out of tree stuff. So the
OS independent stuff is going to get completely re-worked. It's
mechanical
On Mon, Jun 12, 2017 at 01:44:09PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
> > > 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
On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
> > 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
Hello Dave,
12.06.2017 09:27, Dave Airlie wrote:
On 12 June 2017 at 16:56, Hans de Goede 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
Hi,
On 12-06-17 09:27, Dave Airlie wrote:
On 12 June 2017 at 16:56, Hans de Goede 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
On 12 June 2017 at 16:56, Hans de Goede 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
25 matches
Mail list logo