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_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7287 invoked from network); 8 Mar 2023 12:53:42 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 8 Mar 2023 12:53:42 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B2BB041279; Wed, 8 Mar 2023 22:53:38 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.168]) by minnie.tuhs.org (Postfix) with ESMTPS id 3E09541277 for ; Wed, 8 Mar 2023 22:53:29 +1000 (AEST) X-KPN-MessageId: 354e9001-bdb0-11ed-a1d8-005056aba152 Received: from smtp.kpnmail.nl (unknown [10.31.155.39]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 354e9001-bdb0-11ed-a1d8-005056aba152; Wed, 08 Mar 2023 13:53:22 +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=CPbzUGZ03SYgoJKQS6X0DZuGe4AIYad5gicKCBaM83U=; b=SNz89XbgyyucTqOhneGX+y3N9qLz4oWBlEaBT/FxJ/xVeEHF/j7vJwSgIwUDuM71D8FDGGutBGdHN oDOKk/TZUi03NOzlMDw1XuiKHAd8q1p+8vjQb9LrBmsyZ+tdQQSk6WTDPQtOPVJDl+uK2mygpH5Rs6 e5p66YWAYXLbz7Mc= X-KPN-MID: 33|gth7ShieAa1FRxafqw2/DRWfV0v4tVwAyUjJXweSbGT294xG18gV6at6wr+lwhy kZ+ev3h1ApvKJ7JhRtJbReZi+xmEx86ONL3j3VaWNyAE= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|yvtyKEy89ig/HtIUw3NqVkFjSP4n2X44I6qmsxyMfq7dMPNlGDwbhmsF3q1m8pg o2YOR2VYLnZCHCIcbzy3akQ== 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 352b46ae-bdb0-11ed-ab4c-005056ab7447; Wed, 08 Mar 2023 13:53:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Paul Ruizendaal In-Reply-To: Date: Wed, 8 Mar 2023 13:53:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> To: "tuhs@tuhs.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) Message-ID-Hash: 7XETKCZRX5M2Q37PEPGDDDKSTZ7QPIGQ X-Message-ID-Hash: 7XETKCZRX5M2Q37PEPGDDDKSTZ7QPIGQ 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 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: > There is some playing around with the software model, but basically we = have a powerful, privately managed external "card" that does the = graphics, and we talk to it with one particular mechanism. During my = work on Plan 9, it got harder over time to try new things because the = list of ways to talk to the card was shrinking, and other than the = blessed ones, slower and slower. >=20 > For example, a shared-memory frame buffer, which I interpret as the = mechanism that started this conversation, is now a historical artifact. = Back when, it was a thing to play with. Ah, now it is clear. This also has a relation to the point about what constitutes a = "workstation" and one of the comments was that it needs to have = "integrated graphics". What is integrated in this historical context -- = is it a shared memory frame buffer, is it a shared CPU, is it physically = in the same box or just an integrated user experience? It seems to me = that it is not easy to delineate. Consider a Vax connected to a Tek = raster scan display, a Vax connected to a Blit, Clem=E2=80=99s Magnolia = and a networked Sun-1. Which ones are workstations? If shared memory is = the key only Clem=E2=80=99s Magnolia and the Sun-1 qualify. If it is a = shared CPU only a standalone Sun-1 qualifies, but its CPU would be = heavily taxed when doing graphics, so standalone graphics was maybe not = a normal use case. For now my rule of thumb is that it means (in a = 1980=E2=80=99s-1990=E2=80=99s context) a high-bandwidth path between the = compute side and display side, with enough total combined power to drive = both the workload and the display. This is also what is underlying the question about the /dev/fbdev etc. = devices. In Unix exposing the screen as a file seems a logical choice, = although with challenges on how to make this efficient. SunOS 1.1 had a /dev/fb device that accesses the shared memory frame = buffer. It seems that Sun made 4.2BSD mmap work specifically for this = device only; only later on this became more generic. The 1999 Linux = /dev/fbdev device seems to have more or less copied this SunOS design, = providing the illusion of a shared memory frame buffer even when that = was not always the underlying hardware reality. Access to acceleration = was through display commands issued via ioctl. Early Plan9 has the /dev/bit/screen device, which is read-only. Writing = to the screen appears to have been through display commands written to = /dev/bit/bitblt. Later this was refined into the /dev/draw/data and = /dev/draw/ctl devices. No mmap of course, and it was possible to = remotely mount these devices. Considering these abstractions, did it = matter all that much how the screen hardware was organised? The 1986 Whitechapel MG-1 / Oriel window system used a very different = approach: applications drew to private window bitmaps in main memory, = which the kernel composited to an otherwise user-inaccessible frame = buffer upon request. In a way it resembles the current approach. I=E2=80=99= m surprised this was workable with the hardware speeds and memory sizes = of the era. However, maybe it did not work well at all, as they went out = of business after just a few years.