[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New GNU/Hurd project: Crust Display System

From: Kevin Kreamer
Subject: Re: New GNU/Hurd project: Crust Display System
Date: Mon, 20 Aug 2001 12:43:55 -0500
User-agent: Mutt/1.2.5i

On Mon, Aug 20, 2001 at 03:20:05PM +0200, Niels M├Âller said:
> What I think would be terribly useful is a decent frame buffer
> device/translator. The goal would be to make sure that ordinary users
> should be able to hack away at alternative graphic environments,
> without harming other users, and, as far as possible, without shooting
> themselves too hard in the feet. After all, that kind of flexibilty is
> what the HURD is about.

I've been investigating doing something of this sort.  Unfortunately, I 
don't know much about HURD and Mach (yet), so I'm still in the 
discovery phase.  And since I don't have any code, that's why I haven't 
announced anything yet.

Just so everyone knows, I am not looking to replace X.  I'm wanting 
something lower-level for X to run on top of, instead.  My short-term
goal is for virtual terminals on the console with letter sizes different 
than 80x25.  Long term, I want to write something general enough so 
that the graphics mess that has happened with Linux doesn't happen on 
HURD (i.e. text console, fb, kgi, X, etc. all fighting over the 
graphics hardware and able to mess it up for all the others).  Anyway, 
I am far from even a general specification, and still looking at colortext, 
screen, Linux's kernel, FreeBSD's syscons, gnumach, oskit-mach, hurd, 
kgi, svgatextmode, and so on... (so therefore I should have an idea of
how to even attack this problem about, say, 2011 :-).

> There ought to be a well-defined interface or boundary between the gfx
> backend and the user interface widgetry (and then there's another
> boundary between this machinery and applications), so that you can
> replace either part without throwing away the rest of the system.

I agree.  There needs to be some well-defined interfaces.  KGI comes 
closest to what we need, IMHO.  But I'm not sure about any of this, 
that included :-)

Kevin Kreamer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]