src-test2/sys/dev/syscons/sysmouse.c, branch release/11.3.0

Revert r330897:

2018-03-29T02:50:57Z

This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re)

Partial merge of the SPDX changes

2018-03-14T03:19:51Z

These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg

MFC r325295:

2017-12-04T21:12:05Z

evdev: Lock Giant around keyboard ioctls This fixes turning ukbd(4) LEDs on/off with evdev interface as well MFC r325296: evdev: Take driver's lock in cdev write handler if necessary MFC r325297: sysmouse(4): Fix ums(4)-style T-axis reporting via evdev protocol - 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 MFC r325298: evdev: Disable value normalization and state filtering for SND events. Some events can take sound pitch as a value so can not be represented as binary on/off events. Tracking for on/off state is left in place as it is a part of the evdev API. MFC r325299: evdev: Do not start/stop softrepeat callout if no clients attached Approved by: gonzo (mentor)

MFC r309823:

2016-12-22T21:29:57Z

[evdev] Adds evdev support to sysmouse(4) driver 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 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.