offtopic help request (?)

2004-05-17 Thread Iñaki Etxebarria
Hi all, I am working on a system level debugger ( pICE ) and I am giving universal 
output  support to it. I use Linear FrameBuffer by direct writes and it works pretty 
well.

The problem is, that by now, calculations for drawing are based on fixed X,Y,BPP(color 
depth) resolution, which is a bit annoying...

So I´d like to detect those X,Y and BPP each time the system debugger is fired up 
(HOTKEY pressed or breakpoint or other ints triggered). I read something about usong 
CRT regs but I don´t really know how. Also, I have also seen some MMIO stuff, but no 
idea...

One important thing is that -being a system level debugger- it can´t be a call 
driver or call kernel approach, I must do direct hardware ( IO ports or memory ) 
only, since when the debugger is active, the whole system is frozen and I cant rely on 
other stuff than my own code or direct hardware.

Well, hoping its not too off topic :S... Im sorry but I couldnt manage to find any 
help elsewhere... :(

Thanks in advance,

   sheroc.


http://webmail.wanadoo.es. Tu correo gratuito, rápido y en español

Re: offtopic help request (?)

2004-05-17 Thread Tim Roberts
Iñaki Etxebarria wrote:
Hi all, I am working on a system level debugger ( pICE ) and I am giving universal output  support to it. I use Linear FrameBuffer by direct writes and it works pretty well.
 

How are you determining the address of the frame buffer?
The problem is, that by now, calculations for drawing are based on fixed X,Y,BPP(color 
depth) resolution, which is a bit annoying...
So I´d like to detect those X,Y and BPP each time the system debugger is fired up (HOTKEY pressed or breakpoint or other ints triggered). I read something about usong CRT regs but I don´t really know how. Also, I have also seen some MMIO stuff, but no idea...
 

There is simply no generic way to do this.  Every graphics card is 
different.  If you are using the VESA BIOS calls to fetch the address of 
the frame buffer, the same interface can be used to fetch the current 
mode, but there is no guarantee that the VESA BIOS has the current 
information.  You could try parsing /var/log/XFree86.0.log, but that's 
only accurate if XFree86 happens to be running and in the current VT.

You could try running a process periodically to do the equivalent of 
xdpyinfo.  That gives you resolution and depth, but not the frame buffer 
address.  Plus, that doesn't help if a console VT happens to be visible.

One important thing is that -being a system level debugger- it can´t be a call driver or 
call kernel approach, I must do direct hardware ( IO ports or memory ) only, since when the 
debugger is active, the whole system is frozen and I cant rely on other stuff than my own code or direct 
hardware.
Now you know why the best kernel debuggers for Windows use a
--
- Tim Roberts, [EMAIL PROTECTED]
 Providenza  Boekelheide, Inc.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel