From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7342 invoked from network); 6 Mar 2023 11:09:48 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2023 11:09:48 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id DC4294124E; Mon, 6 Mar 2023 21:09:44 +1000 (AEST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by minnie.tuhs.org (Postfix) with ESMTPS id B14644123C for ; Mon, 6 Mar 2023 21:09:35 +1000 (AEST) Received: by mail-lf1-x131.google.com with SMTP id k14so12182668lfj.7 for ; Mon, 06 Mar 2023 03:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678100973; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=wQGQVArvhJk5dmVfxlwojmzakMU31XlpZU+3zV2byts=; b=i8g1rI6j3dJeGyd5KnkpRMqTYqnGOm+JeaJ2Nov7BGJjlM0ofxTdHf/p65p09F4qgy FuhyUkv9gMEkZ/Ryo+BrNPbNNNHipVtNxU0ROuK/xijxrFn+i20DQNtTJC7w8tyb8bpG SSDxe1+9L5N3FhKQeCD3m7CnjRoOf5jSCxhlPTgVn29Mk9MWsX3vINvabGg5MW9ysC1n ll9nTiYo0jxlpOdMwUxEzlsvrv+BSZDdDiHJEhPVbeObaCekGBbHBsQ1Fr9ww5azugb0 gNfE9pOPV6sMXim8jQ0hsU13w0WXX4jPnc8ZG6jT2oMd1wAti8xPVDkSxXPVJu25ggZL XhWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678100973; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wQGQVArvhJk5dmVfxlwojmzakMU31XlpZU+3zV2byts=; b=LYGelXTuEd9FdTmE4eseZ6/GGtpFG7V2OA1bashR1aNjDRV+eJznxqvRWo5Dr3z9Pf +9m8rQgwUBWLERq0AqZICljDWDji/QYhEyBJBaqyFAXArVQWm3J3KJHVVHbpB0wYBFFN PGtBnIwqUwxk1Z2tm1kdHeWnLD8ccM4RLWGSY9POHXoU8yb+N83zfJ/lovml0dcp5n/n d+KV/bgVDnsZkU4oRBslUdbxHdibTxTTLV09gDo3sxVQ2OQU9kt8+j5L4LKMOvD6vYzM dYiqvwi/By1bhRV5KaQUJr0bUV+7wz6N6i+pv07MV7FV7yS0fhd9muJC2YZK410sR7jX oM9w== X-Gm-Message-State: AO0yUKVVUeCJuJy69RBIw0J/mvdVOj5VQy34uZmh7ndNP7blP1KsuIpz 24NA8q+Xzopm03MX2aR82vT+Aaazjii2D3qltuJEehrs758= X-Google-Smtp-Source: AK7set+KIecj2ECPeMkXcLFsLkSHUzgCcTSkJ+ps7X6u3YzCGd6CeZT0mvIkM3KUpVQ/+xDj8Mf5RUVNHDBKZ746MuM= X-Received: by 2002:ac2:4911:0:b0:4d5:ca32:6ae0 with SMTP id n17-20020ac24911000000b004d5ca326ae0mr2951821lfi.0.1678100973309; Mon, 06 Mar 2023 03:09:33 -0800 (PST) MIME-Version: 1.0 References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> In-Reply-To: From: Henry Bent Date: Mon, 6 Mar 2023 06:09:22 -0500 Message-ID: To: "tuhs@tuhs.org" Content-Type: multipart/alternative; boundary="00000000000069541b05f639543f" Message-ID-Hash: QG4OPHHPVQQQNDZGTU7D34VBVZK3EJAW X-Message-ID-Hash: QG4OPHHPVQQQNDZGTU7D34VBVZK3EJAW X-MailFrom: henry.r.bent@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Origins of the frame buffer device List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000069541b05f639543f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 > 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=E2=80=99ve 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 p= art >> of the SunWindows software. My understanding of the latter is still limi= ted >> though. The later Linux usage is designed around mmap() and I am not sur= e >> when that arrived in SunOS (the mmap call exists in the manpages of 4.2B= SD, >> but was not implemented at that time). Maybe at the time of the Sun-1 an= d >> Sun-2 it worked differently. >> >> The frame buffer hardware is exposed differently in Plan9. Here there ar= e >> device files (initially /dev/bit/screen and /dev/bit/bitblt) but these a= re >> not designed around mmap(), which does not exist on Plan9 by design. It >> later develops into the /dev/draw/... files. However, my understanding o= f >> 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 >> wrote: >> > >> > The first frame buffers from Evans and Sutherland were at University o= f >> 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 >> 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 i= n >> nature (a character device that could be mmap=E2=80=99ed to give access = to the >> hardware frame buffer, and ioctl=E2=80=99s to probe and configure the ha= rdware). Is >> that correct, or were these entirely different in nature? >> > >> > Paul >> > >> >> --00000000000069541b05f639543f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The paper Rob refers to is https://dl.acm.org/doi/10.1145/363347.363368<= br>

-Henry

On Mon, 6 Mar 2023 at 03:57, R= ob 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 abou= t a decade now the bearings on that wheel have rusted solid, and no one see= ms interested in lubricating them to get it going again.

-rob

<= /div>
O= n 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=E2=80=99ve now read through SunOS man pages and it would seem that the /d= ev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. Not qu= ite 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 li= mited 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 d= evice files (initially /dev/bit/screen and /dev/bit/bitblt) but these are n= ot designed around mmap(), which does not exist on Plan9 by design. It late= r develops into the /dev/draw/... files. However, my understanding of graph= ics 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 pro= blem. Arguably it still is.



> On 5 Mar 2023, at 19:25, Kenneth Goodwin <kennethgoodwin56@gmail.com> w= rote:
>
> The first frame buffers from Evans and Sutherland were at University o= f 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 b= y=C2=A0 Martin Schaller and=C2=A0 Geert Uytterhoeven (and some input from F= abrice Bellard?).
>
> However, it would seem at first glance that early SunOS also had a fra= me buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in natu= re (a character device that could be mmap=E2=80=99ed to give access to the = hardware frame buffer, and ioctl=E2=80=99s to probe and configure the hardw= are). Is that correct, or were these entirely different in nature?
>
> Paul
>

--00000000000069541b05f639543f--