Re: nanoGui development
> Why is that? to keep the kernel smaller? My initial idea matched with Yes. And also because you may be restoring to another graphical app..
RE: nanoGui development
Why is that? to keep the kernel smaller? My initial idea matched with yours in that user mode should do everything. It certainly would be simpler. However, Alistair suggested the kernel should refresh... On Wednesday, May 05, 1999 1:55 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: > > could be stopped from trashing the screen. I also like the screen refresh being >kernel's > > responsibility. > > On x86 the refresh is the user space programs job. It should save/restore the > text maps > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: nanoGui development
>
> I have had some thoughts on the best way to support graphics. I think it
> would be cleanest to implement an ioctl in the dircon driver telling that
> an application requires graphics so it has to save the contents of the VCs,
> and disable VC switching, and writes to VCs. This then leaves a user space
> vga library to do what it wants with the hardware until it has finished,
> whereupon it call the driver again letting it know that the VCs should now
> be restores. Putting the display hardware back into the right mode should
> be the responsability of the library code.
> >
Sounds good. If the kernel switched modes, then printk() and other things
could be stopped from trashing the screen. I also like the screen refresh being
kernel's
responsibility.
> > o A mouse driver (this is more of a pain, we could still leave it out of the
>kernel)
>
> Could we restrict support to serial mice initially? The serial driver works
> so far.
Absolutely. With the new mouse driver api, a quick stub could be written
for just what ELKS supports. I haven't decided who should decode the mouse
stuff though. Currently, nanogui uses GPM repeater mode that allows nanogui
to decode logitech style mouse codes only...
>
> >
> > o Kernel select() support for mouse and keyboard fd's (note that we require
> > tty ~ICANON raw mode. (^C signal handling would be nice to abort the server on
>bad errors)
>
> We cave non-canonical mode (try running vi), but some other term features
> are still not possible. I have thought about ctrl-C (and ctrl-Z) but have
> not yet come up with a way of implementing them.
The only issue with ctrl-C is to get the SIGINT signal from the kernel. Do
signals
work now in ELKS? If so, of course the tty drivers just ksignals SIGINT.
>
> >
> > o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone
> > wants my ansi modifications, I'm thinking of releasing it myself.
>
> Most ANSI code will compile under bcc if you use the -ansi flag. How much
> do your ansi modifications do? DO they check prototypes, or just allow ANSI
> code to be compiled?
You would ask the hard question. No, my bcc mod doesn't yet support
prototype checking, but it will compile ansi, which in certain cases, like the
following
code, bcc -ansi won't work:
#define feof(fp)(fp->feof)
int (feof)(int fd) { }
The above is a obscure ansi feature that allows function names and defines to
have the same name bcc now compiles this (which the minix libc source uses...)
>
> My previous experiences with ELKS have shown that portable code does not
> always make it very ELKS friendly. I have often had to take code which is
> easily portable, and make it very unportable to make it small enough to run
> under ELKS. In an ideal world we could run nano-GUI from the standard code
> base under ELKS, but it may end up being the case that a heavily modified
> version of nana-gui gives much better performance under ELKS.
>
> Al
Having spent alot of time looking at and compiling ELKS, I think
I can produce a nanogui that will run without much modification.
Greg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: nanoGui development
> could be stopped from trashing the screen. I also like the screen refresh being >kernel's > responsibility. On x86 the refresh is the user space programs job. It should save/restore the text maps
Re: OFF TOPIC
On Wed, 5 May 1999, Jonathan Hall wrote: > 3) Linux won't tell you the CPU Mhz, but your BIOS should. Not quite true. There's a trick that the kernel is doing at the moment which seems to be able to figure out the CPU clock speed. I dunno if that's coming from BIOS or what, but it looks fairly accurate, even on older machines. Davey
Re: OFF TOPIC
> 1) This is WAY off topic for a mailing list that deals with 4.77Mhz CPUs > primarily > > 2) There's no such thing as kernel 2.0.38 > > 3) Linux won't tell you the CPU Mhz, but your BIOS should. The newer kernels do (or at a minimum, claim to): bash$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 1 model name : Pentium Pro stepping: 7 cpu MHz : 199.436034 <--- cpu clock speed cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov bogomips: 199.07
Re: nanoGui development
Greg Haerr writes: > > Alistair - > I've got the nanoGui project moved up quite a bit. It now runs the sample > programs pretty well. As Alan mentioned, I'll be checking all this stuff in shortly. I look forward to looking at the code. > I've also made a makefile option that allows the graphics application to be linked > directly with the nanoX server. This means that you won't have to implement any >sockets > in the ELKS kernel for initial testing. Following are the things that someone will >have > to worry about (I'm planning on getting to these, but I still can't develop on ELKS, > and cross-development is a pain... BTW I have the bcc tools source hacked to > self-host now, for instance it will compile the ANSI C Minix libc source on Minix...) > Anyway, the following needs to be addressed for nanoGui on ELKS: > > o A real mode VGA driver (we can use int 10h for this, pretty easy, then > hack bogl for 16-bit ints) BTW this driver also needs to switch between text > and graphics modes, rather than using consoles. I recommend that all the >graphics/text > stuff remain in nanoGui for ELKS for the time being, we don't need a bigger kernel >for this. > Taking this approach means that ELKS can leave out all graphics stuff from the kernel > for the time being. I have had some thoughts on the best way to support graphics. I think it would be cleanest to implement an ioctl in the dircon driver telling that an application requires graphics so it has to save the contents of the VCs, and disable VC switching, and writes to VCs. This then leaves a user space vga library to do what it wants with the hardware until it has finished, whereupon it call the driver again letting it know that the VCs should now be restores. Putting the display hardware back into the right mode should be the responsability of the library code. > > o A mouse driver (this is more of a pain, we could still leave it out of the >kernel) Could we restrict support to serial mice initially? The serial driver works so far. > > o Kernel select() support for mouse and keyboard fd's (note that we require > tty ~ICANON raw mode. (^C signal handling would be nice to abort the server on bad >errors) We cave non-canonical mode (try running vi), but some other term features are still not possible. I have thought about ctrl-C (and ctrl-Z) but have not yet come up with a way of implementing them. > > o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone > wants my ansi modifications, I'm thinking of releasing it myself. Most ANSI code will compile under bcc if you use the -ansi flag. How much do your ansi modifications do? DO they check prototypes, or just allow ANSI code to be compiled? > > > Currently, NanoGui implements a decent subset of low-level X primitives, >although > they're renamed. Window creation, GC manipulation and text routines work. We still > need some better low-level drawcode support. For instance, XOR drawing isn't done >yet. > > My plan is to take nanoGui and abstract the mouse, keyboard and screen > interfaces into fully defined interfaces within structures, that would allow nanoGui >to become > completely portable with anyone able to roll their own drivers. I should have this >work done > in a couple of days. I've got to hook up my linux box to the net to use the CVS >checkin, > hopefully that'l get done tonight or tomorrow. > My previous experiences with ELKS have shown that portable code does not always make it very ELKS friendly. I have often had to take code which is easily portable, and make it very unportable to make it small enough to run under ELKS. In an ideal world we could run nano-GUI from the standard code base under ELKS, but it may end up being the case that a heavily modified version of nana-gui gives much better performance under ELKS. Al
RE: BIOS get code
Hi Raude. >> I just writes out 64k at 0xF000:0 to 'bios.rom'. > I tried your program on my hp200lx , it's ok. If someone wants > to have a look at its bios, I can send the file. If you can, I'll have a look at it and see what I can work out... Best wishes from Riley. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
Re: OFF TOPIC
1) This is WAY off topic for a mailing list that deals with 4.77Mhz CPUs primarily 2) There's no such thing as kernel 2.0.38 3) Linux won't tell you the CPU Mhz, but your BIOS should. On Wed, 5 May 1999, Rivalino Matias Junior wrote: > Hello, > > How can I get the real clock of my processor ? I'm using the information > storaged in BIOS SETUP, however this field (clock processor) is free for > the user switch. In this case, I don't have 100% confirmation about this > information. The /proc/cpuinfo, in my Linux box, don't present the clock > processor information. My kernel is 2.0.38 (RH). The label printed in my > processor is AMD K6-II 350. However, the performance is pool, that call > me attention. > > Thanx in advance, > > RMj. > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Jonathan Hall * [EMAIL PROTECTED] * PGP public key available Systems Admin, Future Internet Services; Goessel, KS * (316) 367-2487 http://www.futureks.net * PGP Key ID: FE 00 FD 51 -= Running Debian GNU/Linux 2.0, kernel 2.0.36 =- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OFF TOPIC
Hello, How can I get the real clock of my processor ? I'm using the information storaged in BIOS SETUP, however this field (clock processor) is free for the user switch. In this case, I don't have 100% confirmation about this information. The /proc/cpuinfo, in my Linux box, don't present the clock processor information. My kernel is 2.0.38 (RH). The label printed in my processor is AMD K6-II 350. However, the performance is pool, that call me attention. Thanx in advance, RMj.
RE: BIOS get code
>From: Perry Harrington >To: [EMAIL PROTECTED] >Subject: BIOS get code >Date: Wednesday 5 May 1999 08:30 >I wrote a little C program to fetch the ROM BIOS of a machine. >I wrote it on my Compaq Portable III with TC 2.01. The source >is included, you can get the binary and sample Compaq ROM from >ftp.apsoft.com:/pub/users/perry/tc/ >I just writes out 64k at 0xF000:0 to 'bios.rom'. I tried your program on my hp200lx , it's ok. If someone wants to have a look at its bios, I can send the file. Riwal Raude [EMAIL PROTECTED]
BIOS get code
I wrote a little C program to fetch the ROM BIOS of a machine.
I wrote it on my Compaq Portable III with TC 2.01. The source
is included, you can get the binary and sample Compaq ROM from
ftp.apsoft.com:/pub/users/perry/tc/
I just writes out 64k at 0xF000:0 to 'bios.rom'.
--Perry
--
Perry Harrington Linux rules all OSes.APSoft ()
email: [EMAIL PROTECTED] Think Blue. /\
---
#include
#include
void main(void)
{
charfar *bios_data;
FILE *out;
bios_data = MK_FP(0xf000, 0x0);
out = fopen("bios.rom","wb");
if (out == NULL) {
printf ("Failed to open bios.rom\n");
exit(1);
}
fwrite(bios_data, 0x, 1L, out);
fclose(out);
exit(0);
}
