src/sys/dev/syscons/sysmouse.c, branch release/12.3.0

Drop MOUSE_GETVARS and MOUSE_SETVARS ioctls support.

2018-06-10T10:23:31Z

These ioctls are not documented and only stubbed in a few drivers: mse(4), psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS implemented in psm(4) Given the fact that they were introduced 20 years ago and implementation has never been completed, remove any related code. PR: 228718 (exp-run) Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D15726

sys/dev: further adoption of SPDX licensing ID tags.

2017-11-27T14:52:40Z

Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.

sysmouse(4): Fix ums(4)-style T-axis reporting via evdev protocol

2017-11-01T22:30:36Z

- Do not report T-axis wheel events as button presses - Reverse T-axis to match Linux - Remove wrong comment. T-axis buttons state should be checked by level not by edge to allow continuous wheel tilt reporting Reviewed by: gonzo Approved by: gonzo (mentor) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D12676

[evdev] Adds evdev support to sysmouse(4) driver

2016-12-10T18:07:16Z

For horizontal (T-axis) wheel reporting which is not supported by sysmouse protocol kern.evdev.sysmouse_t_axis sysctl is introduced. It can take following values: 0 - no T-axis events (default) 1 - T-axis events are originated in ums(4) driver. 2 - T-axis events are originated in psm(4) driver. Submitted by: Vladimir Kondratiev MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D8597

Use a common tunable to choose between vt(4)/sc(4)

2014-06-27T17:50:33Z

With this change and previous work from ray@ it will be possible to put both in GENERIC, and have one enabled by default, but allow the other to be selected via the loader. (The previous implementation had separate kern.vt.disable and hw.syscons.disable tunables, and would panic if both drivers were compiled in and neither was explicitly disabled.) MFC after: 1 week Sponsored by: The FreeBSD Foundation

Allow to disable syscons(4) if "hw.syscons.disable" kenv is set.

2014-06-18T22:23:10Z

Include , instead of doing it through .

2009-11-28T16:25:55Z

I want to prevent the header polution of eventually.

Last minute TTY API change: remove mutex argument from tty_alloc().

2009-05-29T06:41:23Z

I don't want people to override the mutex when allocating a TTY. It has to be there, to keep drivers like syscons happy. So I'm creating a tty_alloc_mutex() which can be used in those cases. tty_alloc_mutex() should eventually be removed. The advantage of this approach, is that we can just remove a function, without breaking the regular API in the future.

Reduce the default baud rate of PTY's to 9600.

2008-11-08T20:40:39Z

On RELENG_6 (and probably RELENG_7) we see our syscons windows and pseudo-terminals have the following buffer sizes: | LINE RAW CAN OUT IHIWT ILOWT OHWT LWT COL STATE SESS PGID DISC | ttyv0 0 0 0 7680 6720 2052 256 7 OCcl 1146 1146 term | ttyp0 0 0 0 7680 6720 1296 256 0 OCc 82033 82033 term These buffer sizes make no sense, because we often have much more output than input, but I guess having higher input buffer sizes improves guarantees of the system. On MPSAFE TTY I just sent both the input and output buffer sizes to 7 KB, which is pretty big on a standard FreeBSD install with 8 syscons windows and some PTY's. Reduce the baud rate to 9600 baud, which means we now have the following buffer sizes: | LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE | ttyv0 1920 0 0 192 1984 0 199 7 2401 2401 Oil | pts/0 1920 0 0 192 1984 0 199 5631 1305 2526 Oi This is a lot smaller, but for pseudo-devices this should be good enough. You need to do a lot of punching to fill up a 7.5 KB input buffer. If it turns out things don't work out this way, we'll just switch to 19200 baud.

Make sysmouse(4) use its own locks, instead of using Giant.

2008-08-24T15:20:44Z

When I changed syscons(4) to work with the MPSAFE TTY code, I just locked all device nodes down using the compatibility feature that allows you to override the TTY's lock (Giant in this case). Upon closer inspection, it seems sysmouse(4) only has two internal variables that need locking: mouse_level and mouse_status. I haven't done any performance benchmarks on this, though I think it won't have any dramatic improvements on the system. It is good to get rid of Giant here, because the third argument of tty_alloc() has only been added to ease migration to MPSAFE TTY. It should not be used when not needed. While there, remove SC_MOUSE, which is a leftover from the MPSAFE TTY import.