On 8 February 2017 at 14:35, Michael Thayer <[email protected]> wrote: > > Hello Jan, > > 08.02.2017 14:14, Jan Petrouš wrote: > [...] >> >> On 8 February 2017 at 13:45, Michael Thayer <[email protected] >> <mailto:[email protected]>> 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. 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). BR. /Jan
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
