[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interfacing with GPM
Re: Interfacing with GPM
Sat, 27 Jul 2019 11:14:34 -0500
I like your approach. The work I am doing on my terminal emulator is necessary to meet the needs of my largest client. Also, many of the environments where the code will be deployed aren't going to be agreeable to lots of new binaries and certainly not new daemons.
That being said, if I toss these ideas together in with Patrick's, I think improving GPM (or a next-gen version of it) so that it emits SGR sequences might be a good approach because then there's a uniform approach to getting mouse data whether that's on the console or in an xterm-style emulator (although, IMO, there are some deficiencies in the SGR protocol that would need to be addressed).
On Thu, Jul 25, 2019 at 4:48 AM Nicholas Marriott <address@hidden
A simple approach rather than making a new terminal emulator would be to
make a wrapper program that intercepts the mouse sequences and passes
everything else through unchanged - a bit like luit. It could get the
mouse information from GPM, Linux kernel APIs, whatever, and send them
to the application as normal X10 or SGR mouse sequences.
That way you wouldn't need every terminal application to add special
support for GPM which is always going to be a losing battle even if it
On Thu, Jul 25, 2019 at 01:09:58PM +1000, Tim Allen wrote:
> On Wed, Jul 24, 2019 at 08:26:27AM -0400, Patrick wrote:
> > The linux console might not be a popular option on the desktop now
> > but what about the internet of things? Lots of times people need text input
> > and don't need to run X.
> The Linux kernel provides graphical (/dev/fb*) and console (/dev/vcsa*)
> output, and input (/dev/input/*).
> Terminal applications want all their input and output to be encoded as
> terminal escape sequences on stdin/stdout.
> It seems to me the simplest approach should be to write a terminal
> emulator that uses the Linux APIs to provide the terminal APIs, mouse
> event included. Trying to use the Linux kernel terminal emulation with
> GPM bolted on the side via a totally different API is always going to be
> awkward, not least because GPM is unmaintained. Even if it wasn't, the
> kernel terminal emulator is a bit weird, and cannot be changed for
> compatibility reasons. If I had to do work without X, I'd much rather
> use a terminal that could be updated and extended.
> Bug-ncurses mailing list
Bug-ncurses mailing list