Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplayttydevices

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

macallan@ wrote:

> On Sun, 7 Apr 2024 14:49:42 +0900
> Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 
> > macallan@ wrote:
> > 
> > > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
> > > > tty devices, especially news68k that can use a putchar function
> > > > provided by firmware PROM as a kernel console device.
> > > > 
> > > > # Details
> > > > 
> > > > The news68k machines have various framebuffer options, but
> > > > most of them are not "dumb" framebuffer that can be handled
> > > > by raspos(9) but some of them have own processors (68000 etc.)
> > > > to handle various acceleration etc. so it's difficult to implement
> > > > framebuffer drivers.  
> > > 
> > > You can use wsdisplay without rasops or a mappable framebuffer.
> > > Examples would be things like newport or crmfb on sgimips.  
> > 
> > It looks both newport and crmfb has copy and erase ops.
> > As I wrote another post, news68k PROM only provides putchar() function
> > (At least there is no info other framebuffer ops).
> 
> There is already code in vcons which uses putchar() to implement
> copy*() ( to avoid slow fb reads ), using it for erase*() is trivial.
> 
> > This means all pseudo terminal ops (backspace, clear screen etc.)
> > are handled by the PROM.  I still wonder if wscons(9) provides
> > proper interface in such case.
> 
> With vcons you can implement pretty much everything using just putchar
> - since there's a character and attribute buffer you just do your
> operations on the buffer and update the screen character by character.
> For copy operations on dumb framebuffers this is usually faster since
> it avoids framebuffer reads which can be painfully slow. Genfb uses a
> lot of tricks like that.
> Not the intended use when I wrote it, but it's a welcome side effect.
> In fact I wrote colour and virtual console support for STI like that,
> didn't commit it because it interferes with the early console support
> which I have no way to test. STI has no inverse operation ( or any ROP
> support at all )  so I implemented cursor() using putchar.
> 
> > > > To support "text only" framebuffer console, we can use putchar
> > > > functions provided by the firmware PROM.  
> > > 
> > > Does it let you draw characters wherever you want with colours of
> > > inverse attrubute?
> > > If so, that's enough for wsdisplay - sti on hppa does just that.   
> > 
> > Probably no color or inverse ops, unless PROM putchar() supports
> > proper escape sequence of them.
> 
> Oh, so it's an entire terminal emulation, not just something that lets
> you draw characters?

Ah, maybe I see misunderstandings among us.

In sgimips crmfb and newport cases, a putchar() function provided
by the firmware just draws a character (glyph) at the cursor
or specified position. All virtual terminal emulation ops are
done in wsdisplay(9) and vcons(9) layer and MD drivers just draw
characters (or whitespace) per vcons pseudo text VRAM attributes.

On the other hand, news68k (and sun) machines have putchar()
that also handles virtual terminal ops like backspace, CR/LF,
and even scrolling at the bottom of screen. In this case
no VT emulation layer is necessary in the kernel side,
so kernel's putc(9) just calls firmware's putchar(),
and for userland processes we can simply pass translated
wskbd inputs to line discipline of the tty device.

That's the reason why I proposed to add register/deregister
APIs to pass wskbd data to romcons tty device.

What do you think about this case?

Thanks,
---
Izumi Tsutsui