Date: Mon, 09 Apr 2012 10:49:41 -0400 From: Brandon Falk <bfalk_bsd@brandonfa.lk> To: Michael Cardell Widerkrantz <mc@hack.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Graphical Terminal Environment Message-ID: <4F82F705.304@brandonfa.lk> In-Reply-To: <86ipha2eiy.fsf@totoro.hack.org> References: <CAGSJxJ7yRZJydw7fNGyTnsykfsJf2Q0VzoFbKX-%2BSgNspiOhoA@mail.gmail.com> <4F55A0EA.8000300@gmail.com> <CAGSJxJ5BBPkrjwGFLomFvoj%2Bh_qaEmqT%2Bi6tVx__tBVf4yZDYg@mail.gmail.com> <CA%2BtpaK3Fp8m%2B0ccAjiAAKj_JJ1nQEYRBSwg_sYEPqOoWJgUfog@mail.gmail.com> <CAGSJxJ7i-fiNQieACQcKVd%2BvrKvL7eMiwHBq60rUKB=8i5vQiQ@mail.gmail.com> <4f5635d4.5Qp6ViEgiFLUuPKI%perryh@pluto.rain.com> <86ipha2eiy.fsf@totoro.hack.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm still avidly trying to work on this idea, but right now the issue seems to be with AMD and NVIDIA not documenting their protocols. Intel does a good job, but I don't have any Intel chips with graphics laying around. Right now I've targeted what I think is the main issue, and that is the closed-protocol GPU. I'm working on a minimal GPU right now on an FPGA. Not sure if it will actually end up going anywhere, but I would really like to see an open-hardware GPU out on the market. Certainly it would not be an NVIDIA or AMD killer, but it would be a good card for people who just want to watch videos, browse the web, run terminals, etc. The main focus of this GPU would be to maximize resolutions and monitors, and minimize cost. Currently it looks like I could run 4 monitors at 1080p for about $50 (that's not taking into account bulk-order costs). I could try to work with nouveau (as I did before) but I'll just never feel ok with using a system that uses 'blobs' (nouveau terms for the bits that are sent to the card without knowing what they really are). -Brandon On 4/8/2012 3:45 PM, Michael Cardell Widerkrantz wrote: > Since Brandon started this in a sort of rambling mood I'm keeping up > with the tradition... This is just what's on top of my mind right now. > > perryh@pluto.rain.com, 2012-03-06 17:05 (+0100): > >> I _think_ SunTools/SunView were proprietary, > Absolutely. > >> although it's possible that Sun released the source code at some >> point. > Much of the actual window system in SunView was implemented in the > kernel, IIRC. That might not be interesting in this case. > > Another system I used on quite memory-starved Sun 3/50s (as little as 4 > meg) and 3/60s and later on SPARCstations, was the Bellcore MGR window > system: > > http://hack.org/mc/mgr/ > > http://en.wikipedia.org/wiki/ManaGeR > > Many users in the Lysator academic computing society where I first met > MGR preferred it to SunView. It was really nice on monochrome monitors > at 1152x900. It's also network transparent so you can run remote > graphics applications. > > MGR was ported to a lot of systems, including FreeBSD. It might still > compile, but it's unlikely to support anything higher than 640x480 on > FreeBSD. If anyone tries to compile it and runs into problems I might be > able to help. Just e-mail me. > > To support higher resolutions on FreeBSD Brandon would have to rewrite > the functions in libbitblit. One way to do it would be to use vgl(3) to > implement the libbitblit functions. Should be pretty straightforward, I > think, and not too much work. > > On the other hand vgl(3) probably only supports VESA so Brandon will > still have to write a special libbitblit for the nvidia card he > mentions. > > MGR doesn't tile windows but Brandon might want to add a mode to do > that. > > MGR has a slightly bothersome license, though, forbidding commercial > sales so this might not be the best way forward. > > On Sun SPARCs under SunOS it was also possible to run a tiling window > system called Oberon. It shares its name with a programming language and > a complete native operating system. Oberon is a complete environment > using the Oberon programming language so it might not be what Brandon > wants but it might be interesting to look at nonetheless. > > I believe Oberon is still available and can run either as a native > operating system or as an environment under other systems. The SPARC > port I used many years ago was running under SunOS but was running > directly on the console. I don't know if there are any modern Oberon > systems that can do that. > > Incidentally, Oberon was one of the inspirations behind Rob Pike's acme > editor on Plan 9. Acme, however, just handles text. Oberon does graphics > as well. > > I've been thinking something along the same lines as Brandon for several > years now: to write a lightweight window system. For many years I > resisted X and kept using MGR, even going so far as porting MGR to > Solaris and to Linux/SPARC just to be able to keep using MGR on more > modern systems. I gave up, I think, around 1994. > > If I would do it again I would probably not work on MGR but I might use > it for some ideas. One thing that MGR does that I wouldn't do was to > force all graphics operations to be done through escape codes in > terminal windows. While it might be great for network transparance it's > not so great for the speed of local programs. > > The Wayland project is interesting but seems very Linux oriented. On the > other hand work on KMS/GEM support on FreeBSD is coming along. It might > be possible to get Wayland running on FreeBSD. I haven't looked into it > myself (yet). > > James Gosling, who wrote both the Andrew window system and Sun's NeWS > (not SunView, the *other* Sun window system, the one with a Postscript > interpreter) has written an interesting paper about window system > design. I have a copy here: > > http://hack.org/mc/texts/gosling-wsd.pdf > > Some people have mentioned Plan 9's 8 1/2 and rio. They are both very > interesting window systems. While I think they have a very clean design > I think they might be problematic to implement in a system other than > Plan 9. > > You see, both 8 1/2 and rio are *file servers*. They make heavy use of > the fact that the namespace of files in Plan 9 is local to processes. > Reading from /dev/mouse from a process under 8 1/2, for instance, means > listening to mouse events in the window that process is running in. > Another process has a *completely separate* /dev/mouse file but is using > *the same name*. Neat, but not very portable. > > I've used 8 1/2 many years ago but haven't used rio. I believe the > difference between them is fairly small, but I might be wrong: I think > rio allows the process to write pixels directly to a window while 8 1/2 > uses special commands written to /dev/bitblt. Right? > > Rob Pike, the author of both 8 1/2 and rio, also wrote several earlier > window systems that are interesting, for intance mtx and mux on the Blit > and its decendants, the AT&T Teletype 5620 DMD, AT&T 630 and 730. Some > software for these terminals/light workstations is still available. See: > > http://www.brouhaha.com/~eric/retrocomputing/att/5620/ > > An entertainging video featuring Pike and the Blit is available here: > > http://www.youtube.com/watch?v=waTL1abCm9I > > Notice that they really felt the need to explain how a mouse works. > Alright, this was 1982. > > An interesting idea I've been thinking about is making a new window > system API at least partially compatible with either MGR's API (not the > escape codes - the C functions) or the AT&T terminal's API, or perhaps > making a compatibility library. This way a lot of fairly nice very > lightweight software like troff previewers et cetera would be available > from the start. > > Is this a waste of time? I don't know. For instance X11 on the grownup > smartphone I use right now, an ARM based netbook from Genesi, is nice to > have but there's very limited memory on the box and I would rather use > the memory for something else. One of my thin clients, an HP t5125 from > 2005, has even less memory: 128 MiB soldered on the motherboard. It > still makes a quite nice diskless workstation but with a more > lightweight window system it would be nicer still. I think there are > many such boxen around that might still be useful. > > Happy hacking, > MC >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F82F705.304>