Date: Sat, 21 Sep 1996 16:36:57 +0200 (MET DST) From: sos@FreeBSD.org To: proff@suburbia.net (Julian Assange) Cc: hackers@FreeBSD.org Subject: Re: SVGATextMode under FBSD Message-ID: <199609211436.QAA00459@DeepCore.dk> In-Reply-To: <199609210731.RAA15662@suburbia.net> from Julian Assange at "Sep 21, 96 05:31:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Julian Assange who wrote:
>
> I have a fetish for large text screens (the one I'm writing this email on
> is 180x60 (8x16 font) 10800 chars on screen at once, that's 5 x as much
> information before my brain). FreeBSD's inability to do this is the
> biggest problem I have with it, so I've started porting linux's SVGATextMode
> package.
Oh, someone down that road again :)
> Which are really just backends to KDADDIO|KDDISABIO and KDENABIO|KDDELIO
> respectively.
>
> Linux impliments KDADDIO/ioperm as a 128 byte bitmap for each process.
> This is the way I'd like to see it in FreeBSD, but I do not understand
> the how inb/outb interacts with the mm system well enough to do this
> confidently (comments on this?). As a crude hack, I intend to wrap
> KDADDIO|ioperm in linux_compat to KDENABIO. iopl wraps cleanly. This
> should be enough to run svgalib programs, which is a big win, IMEO.
We have no prvision for doing this (yet) it _might_ be done in
not so long time..
> ioctl's used for VT resizing etc, most of which do not have syscon/pcvt
> counterparts, but all of which should be relatively easy to impliment.
> In terms of the linux emmulation code, should these be implimented in
> syscons() using the linux defines/values, or as KD* extensions, with
> FreeBSD values, and a linux_compat ioctl() wrapper? I'm in favour of
> VT_* in order to avoid polluting the USL name space.
Syscons uses the winsize structure, and reports back when there is
a resolution change :), the extra VT defines is a linux bogosity :)
All, in all, the way this should be done, is writing a lkm module
that can be loaded and adds the prober ioctl's to the console
driver (well at least syscons). The provisions for this is in the
next update I have for syscons (most of it is allready there).
If you want to do it this way, I'd help where I can, I might
know a trick or two in this area :)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609211436.QAA00459>