(Sorry, luc, for sending this to you twice :-( )
Hello, here is a little background about me: I am new to this list.
I found out about this project while Googling around for hardware
OpenGL acceleration for a Gumstix, and after looking at the Wiki I
became very interested in it (not because of the Gumstix, but because
of the concept and the fact that FPGAs are cool). I am in school, but
have learned some C/C++/Java/Perl/Ruby/Lisp, and a little Verilog, as
well as some circuit design. I am interested in trying to help with
this project, even though what I can contribute is probably minimal.
I have an oldworld Power Mac G3 running Mac OS X 10.3 (it only has
PCI, no PCI-X or AGP), and a Dell XPS400 running Vista, XP, and
Ubuntu Linux (with PCI-Express), if either of those would be helpful
with developing anything. I don't have any experience writing device
drivers, but I would be willing to attempt to learn (I read about
half of Linux Device Drivers, 3rd Edition, and plan on finishing
reading it this summer at some point).
That seems good, though, the pizza box form factor doesn´t present
less
cable than usual, that add an Ethernet cable indeed (I suppose that
the
box is connected to the monitor with a VGA or DVI cable, right ?)
And finally, this is an X-terminal or like a thin-client.
So, as a consumer, I will tell my wish in an other way : why the
graphical card should have to stay in the PC ? Why doesn´t one put it
directly inside the monitor ? Does this way require an X-server on the
g-card ? Does the graphical card in my PC run a x-server ?
Yes, it would make sense to basically just have a monitor with an
ethernet connection and a power cable if all you want is a thin
client, but personally I have a desktop (The beige G3 minitower from
Apple) that has switched monitors 3 or 4 times. buying a $150 video
card each time is not on my to-do list.
Also, other advantages of putting the card inside the PC:
1) The DVI cable has 24 or so pins on it, which is quite tough and
flexible. The bus connection that attaches to the video card has 180
or more pins that are connected. If that was a cable, it would be
large, hard to bend, fragile, etc.
2) Many modern video cards draw a huge amount of power. It is
convenient to just attach to the PC power supply, because when the PC
hibernates/shuts down the video card doesn't draw practically any
power. This is also true of most monitors (they stop displaying when
the signal stops), but it is convenient to have everything together.
3) Protection. I have certainly heard about monitors being hurt/
destroyed, but most people take care of their tower.
4) Standardization. My old beige tower has an ATI Radeon 7200 in 1
PCI slot, an ATA133 controller card in another, and a USB/Firewire
Card in the third PCI slot. It also has ATI Rage Pro 3D graphics on
board. By having the graphics card be a PCI card like every other
Peripheral, it allows for more flexibility for the consumer. I might
decide that having an Ultra-SCSI3 card to have a super-fast RAID is
more important than having the Radeon 7200, so I can simply swap the
cards. I will still be able to handle simple graphics with the Rage
Pro, but no 3D games or the like.
The ethernet idea is an interesting point. One could simply attach
the monitor on a Gigabit network, or on a custom, say, LVDS
connection, and use that to send commands to the screen/graphics card
assembly. That way, you could attach a bunch of monitors and machines
to a network together, and since each graphics card is running the
actual X server, it is simple to have tutorials, etc. In this ideal
network, the "X server" is _actually_ a server, and the client is
actually a client.
If LVDS is more of your thing, the computer could send commands over
something as small as a phone cord or USB Cable (Well, you would
probably use more control signals than that, but maybe Ethernet), and
make it very easy to attach.
Nick S-A_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
