[vbox-dev] Have any non-Linux developers looked at the vboxvideo drm/kms driver?
jan.petrous at tieto.com
Wed Feb 8 13:44:18 UTC 2017
On 8 February 2017 at 14:35, Michael Thayer <michael.thayer at oracle.com>
> Hello Jan,
> 08.02.2017 14:14, Jan Petrouš wrote:
>> On 8 February 2017 at 13:45, Michael Thayer <michael.thayer at oracle.com
>> <mailto:michael.thayer at oracle.com>> wrote:
>>> I'm afraid I will have to ask for a bit of clarification there. My
>> understanding of a frame buffer is an area of (usually video) memory
>> representing the image shown on a screen. You can have more or less as
>> many of those as will fit into video memory and flip between them. You
>> can also have up to 32 virtual screens (the hardware supports 64).
>> Ok, I might describe it vague, so yes - I need more virtual screens each
>> of them with support of framebuffer. So if I enable, for ex. 4 screens
>> (or monitors?), then I expect to have also /dev/fb0 - /dev/fb3 devices,
>> writing to which will be displayed on appropriate virtual screen.
> That is less vague now - you mean Linux frame buffer devices. Currently
no plans for that, but our driver code is probably not the right place to
do it anyway: we use the generic fbdev-on-KMS wrapper in the Linux kernel,
so unless we are using it wrongly in some way (and I just checked that my
two-screen host also only provides one fbdev device) you would need to talk
to the kernel drm maintainers about it.
Yep. That's the reason I'm asking about. As last time I tried to play with
it was exactly in that state = only one /dev/fb on multiscreen enabled VB
I also checked the driver source and the reason is (or better was in time I
looked inside) evident - only single FB node is supported there.
Anyway, thanks for info. I don't need it right now, so it was more matter
of interest then a real request
(even I still see there nice way of enhancement of VB usage).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vbox-dev