Re: Lack of /dev/vtvga0?

On Sat, Jun 23, 2018 at 12:11 AM, Chris H <bsd-lists_at_bsdforge.com> wrote:
> I'm not clear if you're already possibly referring to this. But have
> you tried sc(4) ( SysCons ). If you haven't tried already;
> adding the following to your loader.conf(5) should give it to you:
>
> kern.vty=sc
>
> You can also include it in your custom kernel by adding this to your
> KERNCONF
>
> device    sc
> options   SC_PIXEL_MODE  # adds support for the raster text mode
>
> Hope this helps.

Hi Chris, thanks for responding.

Yup, I'm aware of using kern.vty to fall back to syscons, and SC_PIXEL_MODE to
get framebuffer support via /dev/tty* devices. I actually have a port of the
xf86-video-wsfb driver for scfb [0].

My question is actually specifically in regards to newcons/vt. By checking
`dmesg` I can see that the libvt driver device vtvga0 is instantiated, but
it's not mapped to any file in /dev/ which means I can't send it an IOCTL as I
normally would.

Or perhaps the problem is that with vt_vga loaded, IOCTLs to /dev/tty* devices
only respond to CONSIO IOCTLs and not libvt or FBIO IOCTLs, which is how they
would respond with SC_PIXEL_MODE and kern.vty=sc.

Note that this is with hw.vga.textmode=0, which afaict per vt(4) is not the
default, but at the same time does not seem to actually change anything.

I believe the entire point of libvt was to abstract away the KMS drivers from
the API framebuffer API and allow for dynamic switching of the backend driver
without needing to switch to a different graphics provider or change the
graphics library/framework/environment configuration, and indeed when loading
the binary blobs for the test GPUs I have in the system, a /dev/fb0 magically
appears, but there is no framebuffer device for the basic in-kernel VGA driver
that is used until a more appropriate KMS driver has been loaded (if ever).

[0]: https://github.com/neosmart/xf86-video-scfb/


Thanks,

Mahmoud Al-Qudsi
NeoSmart Technologies