From: Rob Pike <robpike@gmail.com>
To: Paul Ruizendaal <pnr@planet.nl>
Cc: "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: [TUHS] Re: Origins of the frame buffer device
Date: Mon, 6 Mar 2023 19:57:35 +1100 [thread overview]
Message-ID: <CAKzdPgx_HG-w1=eAPdxXduGttjEVVhxD3vOUEZszkT2tNKoaAA@mail.gmail.com> (raw)
In-Reply-To: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl>
[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]
I would think you have read Sutherland's "wheel of reincarnation" paper,
but if you haven't, please do. What fascinates me today is that it seems
for about a decade now the bearings on that wheel have rusted solid, and no
one seems interested in lubricating them to get it going again.
-rob
On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS <tuhs@tuhs.org>
wrote:
> Thanks for this.
>
> My question was unclear: I wasn't thinking of the hardware, but of the
> software abstraction, i.e. the device files living in /dev
>
> I’ve now read through SunOS man pages and it would seem that the /dev/fb
> file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite
> the same though, as initially it seems to have been tied to the kernel part
> of the SunWindows software. My understanding of the latter is still limited
> though. The later Linux usage is designed around mmap() and I am not sure
> when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD,
> but was not implemented at that time). Maybe at the time of the Sun-1 and
> Sun-2 it worked differently.
>
> The frame buffer hardware is exposed differently in Plan9. Here there are
> device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are
> not designed around mmap(), which does not exist on Plan9 by design. It
> later develops into the /dev/draw/... files. However, my understanding of
> graphics in Plan9 is also still limited.
>
> All in all, finding a conceptually clean but still performant way to
> expose the frame buffer (and acceleration) hardware seems to have been a
> hard problem. Arguably it still is.
>
>
>
> > On 5 Mar 2023, at 19:25, Kenneth Goodwin <kennethgoodwin56@gmail.com>
> wrote:
> >
> > The first frame buffers from Evans and Sutherland were at University of
> Utah, DOD SITES and NYIT CGL as I recall.
> >
> > Circa 1974 to 1978.
> >
> > They were 19 inch RETMA racks.
> > Took three to get decent RGB.
> >
> > 8 bits per pixel per FB.
> >
> > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS <tuhs@tuhs.org>
> wrote:
> > I am confused on the history of the frame buffer device.
> >
> > On Linux, it seems that /dev/fbdev originated in 1999 from work done by
> Martin Schaller and Geert Uytterhoeven (and some input from Fabrice
> Bellard?).
> >
> > However, it would seem at first glance that early SunOS also had a frame
> buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature
> (a character device that could be mmap’ed to give access to the hardware
> frame buffer, and ioctl’s to probe and configure the hardware). Is that
> correct, or were these entirely different in nature?
> >
> > Paul
> >
>
>
[-- Attachment #2: Type: text/html, Size: 3519 bytes --]
next prev parent reply other threads:[~2023-03-06 8:57 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-05 15:01 [TUHS] " Paul Ruizendaal via TUHS
2023-03-05 17:29 ` [TUHS] " Grant Taylor via TUHS
2023-03-05 18:25 ` Kenneth Goodwin
2023-03-06 8:51 ` Paul Ruizendaal via TUHS
2023-03-06 8:57 ` Rob Pike [this message]
2023-03-06 11:09 ` Henry Bent
2023-03-06 16:02 ` Theodore Ts'o
2023-03-06 22:47 ` Paul Ruizendaal via TUHS
2023-03-06 23:10 ` Rob Pike
2023-03-08 12:53 ` Paul Ruizendaal
2023-03-08 14:23 ` Dan Cross
2023-03-08 15:06 ` Paul Ruizendaal
2023-03-08 19:35 ` Dan Cross
2023-03-08 16:55 ` Theodore Ts'o
2023-03-08 17:46 ` Clem Cole
2023-03-08 17:45 ` Clem Cole
2023-03-08 18:12 ` segaloco via TUHS
2023-03-08 18:21 ` Larry McVoy
2023-03-08 18:43 ` Kenneth Goodwin
2023-03-08 18:45 ` Steffen Nurpmeso
2023-03-08 22:44 ` Clem Cole
2023-03-09 14:42 ` Paul Winalski
2023-03-06 23:20 ` segaloco via TUHS
2023-03-07 1:24 ` Kenneth Goodwin
2023-03-08 3:07 ` Rob Gingell
2023-03-08 12:51 ` Paul Ruizendaal via TUHS
2023-03-08 13:05 ` Warner Losh
2023-03-08 13:17 ` Arno Griffioen via TUHS
2023-03-07 1:54 ` Kenneth Goodwin
2023-03-05 18:52 Noel Chiappa
2023-03-05 20:43 ` Rob Pike
2023-03-06 10:43 ` Jonathan Gray
2023-03-07 1:21 ` Kenneth Goodwin
2023-03-08 5:43 ` Lars Brinkhoff
2023-03-09 23:24 ` emanuel stiebler
2023-03-10 1:44 ` Lawrence Stewart
2023-03-06 23:16 Norman Wilson
2023-03-06 23:24 ` Larry McVoy
2023-03-07 12:08 ` arnold
2023-03-07 16:42 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKzdPgx_HG-w1=eAPdxXduGttjEVVhxD3vOUEZszkT2tNKoaAA@mail.gmail.com' \
--to=robpike@gmail.com \
--cc=pnr@planet.nl \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).