08.02.2017 14:44, Jan Petrouš wrote:
On 8 February 2017 at 14:35, Michael Thayer <michael.tha...@oracle.com
<mailto:michael.tha...@oracle.com>> wrote:
[...]
08.02.2017 14:14, Jan Petrouš wrote:
[...]
On 8 February 2017 at 13:45, Michael Thayer
<michael.tha...@oracle.com <mailto:michael.tha...@oracle.com>
<mailto:michael.tha...@oracle.com
<mailto:michael.tha...@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[1].
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 config.
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.
Feel free to provide a patch to fix it then if you think this is
something we are doing wrong. It doesn't necessarily have to be a fully
working patch (I would probably change it anyway when I apply it) as
long as it clearly shows what needs changing. No promises of course
that I would make the change, as it is not the most pressing feature,
but the chances are higher than if you don't (and if it is on the
mailing list the knowledge will keep fresh longer).
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).
[...]
Regards
Michael
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
