Personally I think you should finish the R01 before you go on to something “new”. Seems to be the way of things these days. Create something new. Get it so it sort of works. Call it done and move on to the next “new”. That’s a hideous practice.
I’m new to DevTerm and the R01 in particular but there are a few glaring problems that need to be fixed in the existing software for it:
no cursor in the console?!?! In short the fb driver needs to be fixed.
Although the D1 doesn’t offer 3D hardware acceleration it does offer video decoding and 2d accelerations. At the bare minimum the 2d acceleration should be implemented so that the video responds decently. Lets eliminate the inch worming!
Better printer support. Changing fonts (bitmap style, specifically sizes) should be easy and published for using the bare printer driver (/tmp/DEVTERM_PRINTER_IN), without the need for CUPS. Using the printer driver without CUPS produces microscopic print. With CUPS produces huge print only allowing a word or two per line. Huh?!?! In this role CUPS is more of a detriment than an aid and its HUGE. So many uses are soooo much simpler by just pumping data at DEVTERM_PRINTER_IN. That was a great feature! I’ll get into your source one of these days and enlarge the font to a reasonable size. Anyhow there are at least two things that need fixing there.
It was mentioned:
I personally prefer the track ball of all the mobile pointing devices I’ve used. The problem with the trackball on the DevTerm is its spastic. Sometimes you have to spin it 500 times to move a mm. Other times the barest twitch and you’re across the screen. Yes I’ve tried it with and without X acceleration. I prefer it without. But it seems like this should be fixable and it should work smoothly and consistently. Maybe just a firmware fix?
GPM needs to be fixed to work with the DevTerm R01. I haven’t had the time to get to the bottom of this. But I shouldn’t have to. That’s part of the hardware support. It works in X. This is a “Dev” “Term”. It should work in the “term”-inal. All other systems I’ve used it on… it just works.
Full, complete, all patched kernel sources should be readily available. Since your aimed at makers this should be as important as providing an OS image. I’ve not had the time to get to this either…
Sorry, I started out with two things on my mind but then all of the issues started coming to me. You need someone doing some QA to say when something is “done”.
On the *NEW* front:
You know? Back in the mid '80s IBM acknowledged that people were tired of typing their date and time in at EVERY boot. So when they released the AT they added a battery-backed RTC (aka Dallas chip). It also stored MoBo settings and eliminated the need for dip-switches. Well… I keep saying technology is going backwards and here’s a perfect example: I’m back to having to manually inform a computer of the time again!!!
Yes, I know it can get the time from the Internet… So what if the Internet isn’t handy? This is a portable device WiFI will not always be available. Nor should I need it to be. Plus there is the issue of all the date/time stamps being wrong on files manipulated between the time you turn the machine on and it finally gets given the Internet. I really don’t want to add the old “date”, “time” prompt back to my system boot. Besides SystemD would make this a hemorrhoid. That hideous thing needs to die!
So I’d vote for an RTC on the MoBo. This should be standard equipment on ALL computers and SBCs. It can be powered from the rechargeable batteries.
The SUPER-OBVIOUS missing piece is some way to gain access to the pair of GPIO facilities in the DevTerm. I’ve looked! I can’t buy a role of FFC slice off a piece, strip out the needed number of conductors and connect it to my RTC or temperature sensor, or, or … Outside of manufacturing these are unobtanium. So a compact break out board/mechanism would be good. Probably get a bunch of repeat sales, since makers can easily and inexpensively gain access to the things that created the RaspberryPi crowd in the first place.
Of course while your at it you might also come out with a proto-board that plugs in the ext board port. So makers can cobble together their own specific accessories.
I’m all for a quality RISC-V build! Its obvious that Allwinner put the barest effort into the D1. An 8bit RAM bus for a 64bit processor?!?! The ARM64 gets at least 16! Still the PC industry went to a 64bit bus while the CPUs were still limited to 32! More RAM throughput is huge! When you have the replacement module for my DevTerm let me know. I’ll hang the R01 in the museum.
On the OS front: Devuan! Its Debian / Ubuntu without the hang ups and bleeding.
I like what you have so far … but it needs to be finished.