todd@inco.UUCP (Todd O'Connell) (05/06/88)
I'm sorry if these are old requests but I've been on-site for the last several months and have not had access to the net. 1) Does someone have an implementation of X-Windows up and running on the UNIX PC? If so are you willing to share? 2) Is there any way to directly access screen memory? I would like to bring up a segmented graphics package on my 7300 but find it a little abhorrent to do pixrect ops to display a single pixel in a vector draw routine. I would use the graphics driver except that I also want to do some raster work and I don't want to waste 16 bits/pixel for a b/w display. -- /------------------------------------------------------------------------------ | Todd O'Connell | DISCLAIMER: The opinions are my | McDonnell Douglas - Inco | own and in no way reflect the views | 8201 Greensboro Dr., McLean, Va. 22033 | of McDonnell Doulgas or it's | (703) 883-3939 | subsidiaries.
wjc@ho5cad (Bill Carpenter) (05/11/88)
In article <2271@inco.UUCP>, todd@inco (Todd O'Connell) writes: >2) Is there any way to directly access screen memory? I would like to > bring up a segmented graphics package on my 7300 but find it a little > abhorrent to do pixrect ops to display a single pixel in a vector draw > routine. I would use the graphics driver except that I also want to > do some raster work and I don't want to waste 16 bits/pixel for a b/w > display. The screen memory on the UnixPC is a whole different set of chips from regular old program memory. To access it, you'd have to get right down there to the hardware, and Unix won't let you do that except in a privileged kernel mode. If you were especially clever, you could write a device driver for a device that fiddled with screen memory directly. But, when I say clever, I mean with a capital C. Also, you wouldn't be that far ahead, since you would still have to make a system call (which is what you're already doing). Good chance of clobbering the rest of the system as well. BTW, if you do write that kind of device driver (or find some other way of writing to an arbitrary spot on the screen without regard to the window boundaries, etc), I'd give you at least a nickel for a copy. -- Bill Carpenter (AT&T gateways)!ho5cad!wjc
jbm@uncle.UUCP (John B. Milton) (05/15/88)
In article <2271@inco.UUCP> todd@inco.UUCP (Todd O'Connell) writes: ... >2) Is there any way to directly access screen memory? I would like to > bring up a segmented graphics package on my 7300 but find it a little > abhorrent to do pixrect ops to display a single pixel in a vector draw > routine. I would use the graphics driver except that I also want to > do some raster work and I don't want to waste 16 bits/pixel for a b/w > display. The UNIXpc screen memory is located at $420000, and the only way to access that area of memory would be through a loadable driver. This kind of access would screw up the window manager's view of things. John -- John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|osu-cis}!n8emr!uncle!jbm home: (614) 294-4823, work: (614) 459-7641; talk to me about fractals
rrr@naucse.UUCP (Bob Rose ) (05/17/88)
In article <267@uncle.UUCP>, jbm@uncle.UUCP (John B. Milton) writes: > In article <2271@inco.UUCP> todd@inco.UUCP (Todd O'Connell) writes: > > [Is there any way to directly access screen memory?] > The UNIXpc screen memory is located at $420000, and the only way to access > that area of memory would be through a loadable driver. This kind of access > would screw up the window manager's view of things. What about opening `/dev/mem' for reading and writing. Note, I'm note responsible if you miss the screen and hit the drive controller crashing your hard disk. There is an `ioctl' that allows you to get and put thing on the screen. BTW Does anyone know the location or symbol name of the x and y values of the mouse in `/dev/kmem.' There should be a way to open `/dev/kmem' (for reading only) and get these values. Using the tty driver is very SLOOOWWWWWW!!!!!!! (version 3.51)
alex@umbc3.UMD.EDU (Alex S. Crain) (05/17/88)
In article <700@naucse.UUCP> rrr@naucse.UUCP (Bob Rose ) writes: >In article <267@uncle.UUCP>, jbm@uncle.UUCP (John B. Milton) writes: >> In article <2271@inco.UUCP> todd@inco.UUCP (Todd O'Connell) writes: >> > [Is there any way to directly access screen memory?] > >> The UNIXpc screen memory is located at $420000, and the only way to access >> that area of memory would be through a loadable driver. This kind of access >> would screw up the window manager's view of things. > >What about opening `/dev/mem' for reading and writing. >Note, I'm note responsible if you miss the screen and hit >the drive controller crashing your hard disk. It is easier to load a device driver that to do io to /dev/mem, and /dev/mem carries ALL of the dangers of device drivers. Be warned that playing with device drivers can do more damage than simply crashing the machine, a friend of mine thinks that he wrote over the partition table on his hard drive, ther wasn't enough left to be sure. If you want to play with this, PLEASE know what you are doing. On this train of thought though, Does anyone know how works the keyboard controller? and does the mouse do its work through the controller registers, or is that different? If one of the folks with a hardware manual could breifly explain it, I would be most appreciative. For those interesed in poking the video memory, look in <sys/iohw.h> -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
ford@elgar.UUCP (Ford Prefect ) (05/22/88)
In article <700@naucse.UUCP> rrr@naucse.UUCP (Bob Rose ) writes: >In article <267@uncle.UUCP>, jbm@uncle.UUCP (John B. Milton) writes: >> The UNIXpc screen memory is located at $420000, and the only way to access >> that area of memory would be through a loadable driver. This kind of access >> would screw up the window manager's view of things. > >What about opening `/dev/mem' for reading and writing. >Note, I'm note responsible if you miss the screen and hit >the drive controller crashing your hard disk. Neither the video memory nor the drive controller can be accessed by /dev/{k,}mem. In fact, the standard driver won't even allow access into the loadable driver area (above 0x300000). I have a patch that fixes this. >There is an `ioctl' that allows you to get and put thing on the >screen. That is what I would recommend. >BTW Does anyone know the location or symbol name of the x and y values >of the mouse in `/dev/kmem.' There should be a way to open >`/dev/kmem' (for reading only) and get these values. Using >the tty driver is very SLOOOWWWWWW!!!!!!! (version 3.51) In the kernel, there is a "struct msinfo" called "msinfo", which contains the current mouse state, including button states. You would have to nlist for "msinfo" and read in a (struct msinfo). The structure is in <sys/mouse.h> and looks like: struct msinfo { long physmx; /* horizontal */ long physmy; /* vertical */ char mb; /* current button states */ }; The mouse buttons are encoded using the bits MBUTR, MBUTM, and MBUTL, also defined in <sys/mouse.h>. To see this, try (as root) adb /unix /dev/kmem msinfo/XXx Move the mouse a bit and type a "/" [return]. Repeat several times. Note that there is a bug in the keyboard/mouse driver which allows the "physmy" value to go up to 0x2a6, rather than stopping at 0x15b which is where the screen really ends, so be prepared for values that are off the bottom of the screen, even though the pointer is displayed at the last pixel. I have a version of CAPCTRL that fixes this (yes, the bug is in CAPCTRL, beleive it or not. Actually, it is in the original keyboard/mouse driver as well). For some examples of how to read kernel memory in a program, I recommend my "fuser" program, sources for which I will send to anyone who asks. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
ford@elgar.UUCP (Ford Prefect ) (05/22/88)
In article <989@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: > On this train of thought though, Does anyone know how works the >keyboard controller? and does the mouse do its work through the controller >registers, or is that different? If one of the folks with a hardware manual >could breifly explain it, I would be most appreciative. The microprocessor in the keyboard does most of the mouse work. Mouse motions are sent to the main cpu in the same stream as keystroke codes. There is a code that means "here comes some mouse info", and another code that means "Ok, back to keyboard mode". Anything in-between is to be interpreted as mouse motions (given in relative x and y distances and button states.) The keyboard data format is rather interesting. After any key transition (pressing or releasing any key) the keyboard sends an entire list of every key which is currently held down. The driver compares the new state with the previous state to see which key changed, and in which direction (pressed or released). None of this is documented, of course, even in the tech manuals. I'll let everyone guess how I discovered how it works. :-) :-) -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads