Date: Wed, 20 Aug 1997 04:52:56 -0700 From: Jonathan Mini <j_mini@efn.org> To: =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk> Cc: hackers@FreeBSD.ORG Subject: Re: MDA and VGA memory overlaps. Message-ID: <19970820045256.50922@micron.efn.org> In-Reply-To: =?iso-8859-1?Q?=3C199708201041=2EMAA17982=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Wed=2C_Aug_20=2C_1997_at_12=3A41=3A1?= =?iso-8859-1?Q?7PM_%2B0200?= References: <19970820024553.03988@micron.efn.org> <199708201041.MAA17982@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt stands accused of saying : > In reply to Jonathan Mini who wrote: > > I am writing a set of drivers that replaces the syscons driver and manages > > the console via two devices (and a psuedo device) where basically one device is > > the display, (write only) the other is the keyboard (read only) and then the > > psuedo device is a tty the can bind to one of each (display+keyboard pair) and > > possible more (such as a mouse) to implement a tty. Oh, I should mention that > > it would also be possible to have a tty which didn't bind a device, in that > > case it simply would never diplay anything (with no display) or never get input > > (with no keytboard), etc, etc. > > Hmm, why do you need this ??, or are you trying to resolve the "great > unificated console" that was kind of designed a couble of years ago, > but never implemented ?? Nahh. Not "great unificated console" here. Just my perversions to FreeBSD's kernel. One thing I should say is that I don't really plan on making this a wonderous all purpose console driver for FreeBSD general use, in fact, I dont' really plan on releasing the sources, although I have nothing against it :) (I figure that unless I am bound by some legal restriction (read NDA bites) I automatically determine FreeBSD-specific code (such as a driver) to be BSD copywritten :)) Two main reasons : 1) I am going to be running a kernel where (in the end) tty emulation, vtys, etc, etc won't be needed, but graphics output, support for multiple monitors, and the keyboard input will be needed. 2) In the mean time, I want my mono monitor to be able to act as a console for debugging while my VGA monitor shows off the pretty real-time rendering my system is doing. (read debugging console) So, basically, I want to reduce as much bloat as possible, but need to deal with multiple monitors, keyboards, (I have a few keyboards laying around that do input via various fun methods like the parrallel port and serial port) and also multiple methods of accessing display hardware, such as VESA VBE. Mainly, it's "I needed to write a custom console driver, and this was the way I decided to implement it." In the end, I can replace the tty emulator with something like a Teletype emulator, and forget about it. :) > > Well, my problem is this : The MDA memory mapping lies INSIDE the VGA memory > > mapping. VGA uses 0xa0000-0xaffff (for graphics) and 0xb8000-0xbffff, (for > > text) and the MDA uses 0xb0000-0xb0fff. One of the goals of this is to allow a > > system to be able to have both the mda and vga devices configured, and both > > successfully probe/attach within the system. > > My question is : What do I do for memory mapping within the device > > configuration? As I see it I have three chocies : > > a) dont' trakc memory mappings within the config, as syscons does. > > b) don't track memory LENGTH, and give the vga the base of 0xa0000, > > and assume it's base+0x18000 for the position of the text buffer, > > c) make two devices for the vga.. one to handle text and one to handle > > video. I don't even want to think about device contention, although > > the solution is feasable. :( > > > > Right now I am using solution b, since it is simplest to implement. > > Solution c is the only that will work, if you have a monochrome VGA > solution b breaks... If I have a mono VGA card, I can't implement an MDA driver that will coexist with the VGA card, as the two cards would conflict in port addresses. (the mono VGA card uses the MDA's port address) > How are you going to handle the communication thats needed between the > keyboard, mouse and the video driver ?? > (hints: keyboard layouts, virtual consoles, mouse support, misc ioctl's) What's the problem with ioctls? an ioctl would exist to give you the devices the tty emulator was attached to.. from there, you access the device directly if you need to do something the tty emulator doesn't do. (I am assuming you'd "borrow" the device from the tty emulator, so it wouldn't do i/o on that device until you were done. Bleh : keyboard layouts - I plan on there being _two_ modes of keyboard interface. One is used via mmap, the other with read. The mmap method simply gives you a mapped array that states the current status of each key on the keyboard, listed by scancode. I am assuming that the using process/device knows how to interpret that info. The second, via read, gives out ASCII data, in a char-by-char basis, as it is available, i.e. when you press the A key, it spits out an A, on the basis of a keymap lookup. IOCTL's would be used to determine what keymap to use, how it will handle keys not expressed in the ASCII set, but that method gives me the basic typematic support I need. mouse - Actually, I don't plan on implementing mouse support into the tty emulator, since I personally will never use it. I just listed it becuase it was an example of another device you'd want to attach to a tty. (I view the tty as a general "holder" with a simple interface.. pass it to a process, and say "oh, you get to have these devices now") I would think just about any input or output related device could be attached in that manner. (good example is a lightpen or similar device) The tty emulator is responsible for managing what the user DOES with the mouse, so the other code doesn't need to deal with that. (such as the display) The display WOULD have to know how to display a mouse cursor, but oh well. display - all the display does is display stuff. it handles two things : a) dump buffer to real screen buffer. b) dump buffer to real screen buffer through some translation. The only translation I forsee is conversion from a standard text framebuffer type to the framebuffer type for the current video mode. virtual consoles - one per tty emulatior, each emulator stores a framebuffer, and when you switch, the emulator loosing the device stops writing to it, and the emulator gaining it starts writing. In effect, each tty emulator is a virtual console, and it handles it's own info itself. It only uses a display when it has one. Same with keyboard. tty emulators would handle the switches. Basically, it offloads as much "bloat" as possible to the tty emulator, and then whne I dont' compile one into my kernel, I easily remove that bloat from my kernel, and I leave in the support for console i/o that my code needs. (stuff like graphics code) > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970820045256.50922>