The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
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 --]

  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).