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 24010 invoked from network); 6 Mar 2023 08:57:59 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2023 08:57:59 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 280494124A; Mon, 6 Mar 2023 18:57:55 +1000 (AEST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) by minnie.tuhs.org (Postfix) with ESMTPS id 723DB41235 for ; Mon, 6 Mar 2023 18:57:48 +1000 (AEST) Received: by mail-vs1-xe29.google.com with SMTP id f23so8378443vsa.13 for ; Mon, 06 Mar 2023 00:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678093067; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LJTxUXcA4pBmqAgM7ezo/KytjEoofpGrPFva/4X9hmc=; b=JPwP0iwtbvx2gIB+oZGqotXmwfn5C5E++GYzDQadP8kZgYtHYD2o+3T+Yj6IfCWyD3 cX8Yv+26myHwHoT7DW4F2Ct5dKydVWWhXsBOzDtvYVPdV11BbH0zCTkGMvdJwKrkP/3W CneEy3+w1HrA5NI/sKTMSn4tGR/SMqCKwqTNnmVtszMQUBTU3wJi0SorImtBoHe0kptB RXLnSUsrpz6QQ4MXrY7dut3Mkjp6RSjhrO7ll7mSIsTQWfLMJ4XqEnDl9St1Qc5Ny2gD Zbg2fjt6bEMZoO4AdVcfB6sRgtDIcZjSdajZGscfuvloXIOg5BLLIN3Yy25WPzURm0pK o8KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678093067; h=cc: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=LJTxUXcA4pBmqAgM7ezo/KytjEoofpGrPFva/4X9hmc=; b=1Xvp1BrzVMYEuSlWA1v5miyfyPhEzdnM5YY64Iro8OQJHSUuWq2wWYaGRAog25iueo qwp4nQY1+vaIUcDwiuvRXWNA0obzDOGN1VeyrrOUjrqD3liHrZ7zytd37+iQTRrSI8y2 G7eGGcafTmayyllEJ5lmwLuLyFCMulRopob5whMcRJbdcvoamdD/UQByl9RSD3arVjIR WbYTURLhAJrRpTbaD4vESyd6uGjvHDbgMAoMontzZ9TdpOOHU897Ey/E/xvNu+vgSfGf CCg2OOcvyZ+Du4UdcYJAwJCDD330kPstiNJLN1EL//pzb8agNn0Ccsov96CvTHtjDKDZ 3QSg== X-Gm-Message-State: AO0yUKXrjtMlIvMkCFTygNcEQxlrTldgosYhGfcAETz5zE4NxULdvNx8 LVI+gxPBJyZNbWSqQn9r5Y72++CgIDWHByMu+VY= X-Google-Smtp-Source: AK7set8AcsMqZVaDamfcsFqQGix/PbpCTMiNoPng61ZyEUKkVXkoEITq1Ne61V8PMLJlCd9o7myJ7ZV6BmQT2DDMvgQ= X-Received: by 2002:a67:72c5:0:b0:402:99ce:1d9f with SMTP id n188-20020a6772c5000000b0040299ce1d9fmr6793709vsc.4.1678093067026; Mon, 06 Mar 2023 00:57:47 -0800 (PST) MIME-Version: 1.0 References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> In-Reply-To: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> From: Rob Pike Date: Mon, 6 Mar 2023 19:57:35 +1100 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="00000000000029050e05f6377d79" Message-ID-Hash: EGJL65HDUOIRRU7KHBEVSJPIHFPAZTX3 X-Message-ID-Hash: EGJL65HDUOIRRU7KHBEVSJPIHFPAZTX3 X-MailFrom: robpike@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 CC: "tuhs@tuhs.org" 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: --00000000000029050e05f6377d79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 pa= rt > of the SunWindows software. My understanding of the latter is still limit= ed > 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.2BS= D, > 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 ar= e > 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 > 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 > 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 fram= e > buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in natur= e > (a character device that could be mmap=E2=80=99ed to give access to the h= ardware > frame buffer, and ioctl=E2=80=99s to probe and configure the hardware). I= s that > correct, or were these entirely different in nature? > > > > Paul > > > > --00000000000029050e05f6377d79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would think you have read Sutherland's "wheel of reinc= arnation" 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 h= ave 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 Ruizendaa= l via TUHS <tuhs@tuhs.org> wrote= :
Thanks for thi= s.

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
>

--00000000000029050e05f6377d79--