Open-Source DRM Driver Sent Out For The "Good Old" Atari ST/TT/Falcon Systems

[phoronix]

Phoronix: Open-Source DRM Driver Sent Out For The "Good Old" Atari ST/TT/Falcon Systems

As we approach the end of 2022, an initial "request for comments" was sent out this week on a new open-source Direct Rendering Manager (DRM) display driver for supporting Atari systems from the early 90's...

https://www.phoronix.com/news/Atari-DRM-Driver-ST-TT-Falcon

[Akiko]

I really wonder how useful this is. About 2 years ago I took an Amiga with a Cyberstorm Mk3 68060 @66MHz, built a basic Linux 5.19 and busybox using a musl/m68k enhanced OpenADK. Booted this from a Fastlane Z3 to get about 9 MiB/s (and no, the Cyberstorms Wide-Fast-SCSI aka Ultra-SCSI - max 40 MiB/s - is not supported by Linux) and it took at least 2 minutes to get the login/prompt. Also tried that with a Blizzard 1230 with SCSI2 and 256MiB Fast-RAM, here it took ages, at least 6 minutes. It is just not usable. And no, even with a CT-60 at 133MHz this will be absolutely painful.

[kreijack]

I really wonder how useful this is. About 2 years ago I took an Amiga with a Cyberstorm Mk3 68060 @66MHz, built a basic Linux 5.19 and busybox using a musl/m68k enhanced OpenADK. Booted this from a Fastlane Z3 to get about 9 MiB/s (and no, the Cyberstorms Wide-Fast-SCSI aka Ultra-SCSI - max 40 MiB/s - is not supported by Linux) and it took at least 2 minutes to get the login/prompt. Also tried that with a Blizzard 1230 with SCSI2 and 256MiB Fast-RAM, here it took ages, at least 6 minutes. It is just not usable. And no, even with a CT-60 at 133MHz this will be absolutely painful.

I don't think that anybody does that for "usefulness", but only because it is fun. In fact this is how Linux was born:

...I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones..... [1]





[1] https://historyofinformation.com/det...p?entryid=2000

[Chewi]

I really wonder how useful this is. About 2 years ago I took an Amiga with a Cyberstorm Mk3 68060 @66MHz, built a basic Linux 5.19 and busybox using a musl/m68k enhanced OpenADK. Booted this from a Fastlane Z3 to get about 9 MiB/s (and no, the Cyberstorms Wide-Fast-SCSI aka Ultra-SCSI - max 40 MiB/s - is not supported by Linux) and it took at least 2 minutes to get the login/prompt. Also tried that with a Blizzard 1230 with SCSI2 and 256MiB Fast-RAM, here it took ages, at least 6 minutes. It is just not usable. And no, even with a CT-60 at 133MHz this will be absolutely painful.

I don't think my Amiga 1200 with a 33MHz 68030 and 128MB RAM takes as long as 6 minutes, but it's been a while and maybe I was just being patient. It's also a fairly minimal Gentoo system, so exactly what you're starting will obviously make a difference. But yeah, it's just for kicks anyway.

[TemplarGR]

I don't think this should be included in upstream. 2023 is the time such drivers would get dropped from it, not BEGIN to be included in it.... Seriously. It is extremely niche. Anyone who actually wants to use this, can built it himself or use a modified distro/binary for it. I really don't understand what's the point to get it into the kernel in 2023....

[Weasel]

I don't think this should be included in upstream. 2023 is the time such drivers would get dropped from it, not BEGIN to be included in it.... Seriously. It is extremely niche. Anyone who actually wants to use this, can built it himself or use a modified distro/binary for it. I really don't understand what's the point to get it into the kernel in 2023....

Still makes more sense to include this in the kernel than Rust.

So remove Rust first.

[ayumu]

I don't think this should be included in upstream. 2023 is the time such drivers would get dropped from it, not BEGIN to be included in it.... Seriously. It is extremely niche. Anyone who actually wants to use this, can built it himself or use a modified distro/binary for it. I really don't understand what's the point to get it into the kernel in 2023....

The fact that this code has been written and sent for upstreaming NOW is proof enough people care.

We're not talking about some abandoned code for a platform nobody cares about.

[Developer12]

I don't think this should be included in upstream. 2023 is the time such drivers would get dropped from it, not BEGIN to be included in it.... Seriously. It is extremely niche. Anyone who actually wants to use this, can built it himself or use a modified distro/binary for it. I really don't understand what's the point to get it into the kernel in 2023....

Somehow people still don't understand that linux isn't *only* for mainstream hardware. If there is someone willing to support and maintain it, it gets in. There is only one mainline kernel for *everyone,* after all. If people want to run linux on emulated atari systems, let them. It has absolutely no effect on your rando x86 box.

[Developer12]

Still makes more sense to include this in the kernel than Rust.

So remove Rust first.

Obvious troll is obvious.

[jeisom]

Honestly these kind of uses are the type of things that should be in a true fork of linux. A legacy fork, not just a development fork. There are probably a lot of devices that are supported, but not really practical in vanilla linux. Cool that it works true, but but also adds unnecessary maintenance burden and has unnecessary functionality for said hardware.

Now getting the hardware supported in just 1 release means it is supported forever as the patches don’t get lost and the kernel archive has prior releases..