[linux-elitists] The desktop in your pocket

Jason Spence jspence@lightconsulting.com
Mon Jan 26 10:24:29 PST 2004


On Mon, Jan 26, 2004 at 07:55:15AM -0800, Ben Woodard wrote: 
> On Sun, 2004-01-25 at 15:45, Larry M. Augustin wrote:
> > > On Sunday, January 25, 2004 Teh Entar-Nick wrote:
> > >begin Larry M. Augustin  quotation:
> > >> See www.oqo.com.  It's a full PC in a form factor that's close to
> > >> PDA sized.  It plugs into a docking station that allows it to
> > >> function as a desktop computer.
> > >
> > >	What would increase the 'leetness is if the box could address
> > >both internal and external displays separately.
> > 
> > Are there any laptops that can do that?  Seems like you would need two
> > framebuffers, which pretty much means two gpus.
> 
> Mac laptops have been able to do it for at least a decade. I don't know
> about new stuff but the powerbook that I had back at Cisco when I first
> started there 1995.
> 
> The neomagic 256AV in the Toshiba 2100CT that you bought me when I was
> back at VA could theoretically do it, though I never bothered to
> actually rewrite the X driver to make it actually work.
> 
> According to one of the X guys that came over in the Precision Insight
> aqusition I talked to at one point, evidently making a GPU which can
> drive two displays is really not that hard since very little of the
> circuitry in the GPU is actually associated with generating the video
> signal. I know that this is a terrible oversimplification but the way
> that it was said to me was something like, "It is just a couple of
> timers and oscillators." 

Yes, that's correct.  All you need is a RAMDAC with dual outputs and a
control interface that supports whatever you want to do with those
outputs.  

Big Theory Section:

In video memory, there's space for the pixels which are actually
supposed to be drawn on the screen.  This could be located anywhere in
the card's memory these days, now that we all have 64M 3-d whizbang
ninjafied super chips in even the crappy machines.

The main video chip [2] typically has a control interface to another
component on the board called a RAMDAC, which is usually a separate
chip so the VHDL guys don't have to talk to the analog guys too much
:) The RAMDAC also has a data interface to the main video memory, and
can be programmed via the control interface to read a certain chunk of
video memory (where the framebuffer is currently located for the
current mode) [3].  The usual way to screw with the RAMDAC is via
passing a ModeInfoBlock structure to Vesa/VBE 3 interface function 02.
You can get access to the code which is used to translate that into
the video chip's registers by doing this:

1) Read the first few bytes at offset 0xc0000 in real memory (via
   /dev/mem).  You should see 55 AA something, where something is the
   size of the video BIOS in 512 byte chunks.  Read from the 0xc0000
   base up to the limit, which is something x 512 bytes.

2) Look in the block of data you just got for the signature 'PMID'.
   The data following this signature should have the following format:

PMInfoBlock struc
Signature db 'PMID' ; PM Info Block Signature
EntryPoint dw ? ; Offset of PM entry point within BIOS
PMInitialize dw ? ; Offset of PM initialization entry point
BIOSDataSel dw 0 ; Selector to BIOS data area emulation block
A0000Sel dw A000h ; Selector to access A0000h physical mem
B0000Sel dw B000h ; Selector to access B0000h physical mem
B8000Sel dw B800h ; Selector to access B8000h physical mem
CodeSegSel dw C000h ; Selector to access code segment as data
InProtectMode db 0 ; Set to 1 when in protected mode
Checksum db ? ; Checksum byte for structure
PMInfoBlock ends

3) The Checksum field needs to be checked to avoid collisions with
  code which contains the constant 'PMID' as a search key.  The code
  you're looking for is the EntryPoint offset.

The RAMDAC just takes the bits from whatever chunk of main video
memory its pointed at and groups them into scan lines, slaps timing
signals on either end (and at the top and bottom of the line groups),
and outputs it via the VGA or DVI port.  The required speed of the
RAMDAC is roughly the square of the average dimensions of the screen.
As a result, going from (say) 800x600 to (say) 1600 to 1200 requires
that the RAMDAC be 4 times faster.

> The tricky bit and why you don't see it done more is that they are
> sharing video memory bandwidth and all the other circuitry that
> actually converts the high level commands into bits that go into
> that video memory. Since the gamers are obsessed by frame rates that
> is what the market produces.

> What I would like to see is a graphics card that will drive 4-8
> displays. I wouldn't care if it was 1/8th as fast when doing this since
> xterms do not need that much speed but screen real estate is very nice.

There's a company named Christie Digital [1] that I saw used for a
transportation project I'm working on.  The system was pretty slick;
there was a Windows-based system with a bunch of slots with
proprietary video cards in them, and they were doing something with
the GDI layer to make them appear as one logical screen.  The system
took arbitrary inputs, so the fact that its Windows wouldn't prevent
you from using something else as the input.

[1] http://www.christiedigital.com/

[2] What's this GPU bullshit?  It's just screwing around with 2-d
blocks and 3-d matrices in hardware.  I mean no disrepect to the fine
people at the companies that produce this stuff, but it seems to me
that some marketing idiot had a major case of hubris and needs to be
struck down.

[3] Fun things to try #528: override the 3-d drivers and reprogram the
RAMDAC to point at texture or polygon memory on a 3-d card while
something interesting is trying to doodle on a 3-d rendering context,
heh heh heh...

-- 
 - Jason            Currently at: Ohlone College (Fremont, CA) (Mostly Cloudy)

Democracy is a device that insures we shall be governed no better than
we deserve.
		-- George Bernard Shaw



More information about the linux-elitists mailing list