The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Henry Bent <henry.r.bent@gmail.com>
To: "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: [TUHS] Re: Origins of the frame buffer device
Date: Mon, 6 Mar 2023 06:09:22 -0500	[thread overview]
Message-ID: <CAEdTPBf9huZCOZeQC22MAdmKS+Bumeb9TcVnzu8SXSVUcvZrtA@mail.gmail.com> (raw)
In-Reply-To: <CAKzdPgx_HG-w1=eAPdxXduGttjEVVhxD3vOUEZszkT2tNKoaAA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]

The paper Rob refers to is https://dl.acm.org/doi/10.1145/363347.363368

-Henry

On Mon, 6 Mar 2023 at 03:57, Rob Pike <robpike@gmail.com> wrote:

> 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: 3972 bytes --]

  reply	other threads:[~2023-03-06 11:09 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
2023-03-06 11:09       ` Henry Bent [this message]
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=CAEdTPBf9huZCOZeQC22MAdmKS+Bumeb9TcVnzu8SXSVUcvZrtA@mail.gmail.com \
    --to=henry.r.bent@gmail.com \
    --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).