Open allykzam opened 8 years ago
@amazingant - great questions. The framebuffer device is not ready for prime time. We've actually removed it in our develop branch so soon you'll receive a flight where /dev/fb0 will be gone.
If this is preventing a scenario you feel strongly about I'd suggest filing a task on our user voice page and based on interest we can look at a more complete fb0 device in the future...
Thanks for reporting this issue, and thanks for trying out WSL! Ben
@benhillis Thanks for the feedback; I'm certainly disappointed to hear of the device's demise, but I don't have any important uses for it. The only real use I have for frame buffers is fbterm, which I use on my headless systems for those odd times I plug a monitor into them, but that doesn't seem applicable here; Windows already has a UI and wallpaper support. :)
Closing out this thread, thanks again for trying out WSL.
Just quickly pulling apart one of my old projects, calling
ioctl
and passingFBIOGET_FSCREENINFO
andFBIOGET_VSCREENINFO
gives me some basic information about the frame-buffer, and I can see that it has a bit-depth of 16bpp, with a resolution of 800x600. Other fields from the two structures returned (afb_fix_screeninfo
and afb_var_screeninfo
value, respectively) give me bad values; for example, on a 1280x800 display I use, the fixed-info structure reports aline_length
of 5120 (it's got 32bpp, so 1280 x 4 bytes = 5120), but in this environment, the fixed-info structure reports aline_length
of zero?Moving forward anyway, my code tries to map the buffer with mmap, but fails because
buffer
is -1. The relevant code looks roughly like this:Since there's not much of an error from the system, I assume I'm just not allowed read/write access to the buffer.
Is the frame-buffer intended to work at some point, or am I poking a placeholder file that will never do anything?