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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29217 invoked from network); 6 Mar 2023 22:47:58 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 6 Mar 2023 22:47:58 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B62A8411FF; Tue, 7 Mar 2023 08:47:53 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1678142873; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=TBl25bMwAGD9xYxTyuMWHdhJcUz6MndmbSwGtW4vGsk=; b=t1jTKDteAiNTXCxS5BjAtkhWVWNRcmMVs0MQ5ZwHuXvJiooKoZakUARIs2WJIgGI2qd/o/ I0ZzoHDjq2XJ+uQmtzkIyHXdQPCAJ0NEzxnwOlvPYE5qTIG0rrisjHXqBtm7xki/jcwDwB IhvIlYl6yiI3gcUIEcOsq4GPKxR09o8= Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.167]) by minnie.tuhs.org (Postfix) with ESMTPS id B3E16411FE for ; Tue, 7 Mar 2023 08:47:35 +1000 (AEST) X-KPN-MessageId: e0a95006-bc70-11ed-b20d-005056abbe64 Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id e0a95006-bc70-11ed-b20d-005056abbe64; Mon, 06 Mar 2023 23:47:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:message-id:date:from:subject:mime-version:content-type; bh=TBl25bMwAGD9xYxTyuMWHdhJcUz6MndmbSwGtW4vGsk=; b=yQKOZkBFvBqDM1ibWmcfo3qeYhFLyIDY1LZGhlKX3U+jPVu9MawuF/lSezrvTJ2btVEp4c2Qs1qzW zJBRVuyTA7sYkIT/oOEt2CjBiI1Bv4kXYRdfXGzqHGoNIyj2yZlloVVgll0NDAdAeX2+HJoxsOxGDE bnmH/zOqIj0qyD7o= X-KPN-MID: 33|fIieoSpNJ/vpEwZbXI5/qhgrgcvFjkqBQhMhijUWCWG706ais4bVv3jJpV763hg 75NRG/Cw99pf1UtA+Uf3Wsj46pz3BaQPVkyAyfaMrB90= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|5E17tkNJHNa09mHdHwlpiHCsK+3pK3l5PMFCT8nnR4AJP7LaqhVx3n6JvqggMoL 9lE4SAABHC89RUugvcxWbqA== X-Originating-IP: 77.172.38.96 Received: from smtpclient.apple (77-172-38-96.fixed.kpn.net [77.172.38.96]) by smtp.kpnmail.nl (Halon) with ESMTPSA id e0aef2b0-bc70-11ed-97f1-005056abf0db; Mon, 06 Mar 2023 23:47:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) In-Reply-To: Date: Mon, 6 Mar 2023 23:47:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> To: Rob Pike X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: RNSJG6V4BPJRAZTKQMEMKXGAS2OT7VSA X-Message-ID-Hash: RNSJG6V4BPJRAZTKQMEMKXGAS2OT7VSA X-MailFrom: pnr@planet.nl 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: From: Paul Ruizendaal via TUHS Reply-To: Paul Ruizendaal X-Spam: Yes I had read that paper and I have just read it again. I am not sure I = understand the point you are making. My take away from the paper -- reading beyond its 1969 vista -- was that = it made two points: 1. We put ever more compute power behind our displays 2. The compute power tends to grow by first adding special purpose = hardware for some core tasks, that then develops into a generic = processor and the process repeats =46rom this one could imply a third point: we always tend to want = displays that are at the high end of what is economically feasible, even = if that requires an architectural wart. More narrowly it concludes that the compute power behind the display is = better organised as being general to the system than to be dedicated to = the display. The wikipedia page with a history of GPU=E2=80=99s since 1970 = (https://en.wikipedia.org/wiki/Graphics_processing_unit) shows the wheel = rolling decade after decade. However, the above observations are probably not what you wanted to = direct my attention to ... > On 6 Mar 2023, at 09:57, Rob Pike wrote: >=20 > 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. >=20 > -rob >=20 >=20 > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS = wrote: > Thanks for this. >=20 > My question was unclear: I wasn't thinking of the hardware, but of the = software abstraction, i.e. the device files living in /dev >=20 > 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 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. >=20 > 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. >=20 > 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. >=20 >=20 >=20 > > On 5 Mar 2023, at 19:25, Kenneth Goodwin = wrote: > >=20 > > The first frame buffers from Evans and Sutherland were at University = of Utah, DOD SITES and NYIT CGL as I recall. > >=20 > > Circa 1974 to 1978. > >=20 > > They were 19 inch RETMA racks. > > Took three to get decent RGB. > >=20 > > 8 bits per pixel per FB. > >=20 > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS = wrote: > > I am confused on the history of the frame buffer device. > >=20 > > 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?). > >=20 > > 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=E2=80=99ed to give = access to the hardware frame buffer, and ioctl=E2=80=99s to probe and = configure the hardware). Is that correct, or were these entirely = different in nature? > >=20 > > Paul > >=20 >=20