Age | Commit message (Collapse) | Author |
|
after the allocation and initialization is done. Otherwise, a race is
possible if malloc ends up sleeping.
ok sashan@
Reported-by: syzbot+7f8224e9f1a3487caf25@syzkaller.appspotmail.com
|
|
keyboard attached and /etc/kbdtype being present. The advertised
encoding of a wsmux is a bit fragile as the last attached device will
dictate it. If this happens to be a ucc keyboard, KB_US will always be
the advertised encoding as its encoding is immutable and /etc/kbdtype is
ignored.
Instead, do not advertise the encoding for ucc devices when the parent
mux queries its attached devices. However, asking the device directly
(i.e. bypassing the mux) still returns the encoding as wsconsctl(8)
would otherwise report an error.
Thanks to landry@ for the report and testing.
|
|
ok deraadt@
|
|
encoding is supported. Instead, silently ignore such requests. Gets rid
of the following warning emitted by kbd(8) while booting with a ucc
keyboard attached and /etc/kbdtype being present:
kbd: unsupported encoding uk on /dev/wskbd2
I ended up repurposing KB_MACHDEP as is became unused back in 2008. Note
that running a kernel with this commit applied requires kbd and
wsconsctl to be recompiled in order to show correct encodings.
Problem reported by landry@ and ok deraadt@
|
|
Revision 1.29 of wstpad.c has removed the 'maxdist' checks
for multi-finger taps. While this change makes tap detection
more reliable, and does not affect inputs intended for pointer
movement, it might interfere with short scroll gestures.
This version reorganizes the filtering code, and reintroduces
a weaker version of those checks for MT touchpads.
|
|
In order to distinguish tap gestures from short movements, the mechanism
checks whether the distance between the first and the last position of a
touch exceeds the 'maxdist' limit. Some touchpads provide unreliable
coordinates when more than one contact is being made simultaneously, and
in this case the filter may be too strong - and superfluous, because only
one-finger contacts should trigger pointer movement.
|
|
ok gnezdo@
|
|
ok jsg@
|
|
Thanks to RJ Johnson for this work!
ok mpi@
|
|
ok visa
|
|
|
|
OK millert@
|
|
Rename klist_{insert,remove}() to klist_{insert,remove}_locked().
These functions assume that the caller has locked the klist. The current
state of locking remains intact because the kernel lock is still used
with all klists.
Add new functions klist_insert() and klist_remove() that lock the klist
internally. This allows some code simplification.
OK mpi@
|
|
properties must always hold true:
1. A device (wsmouse0 is this scenario) can only be opened in rw mode
once. Such device cannot be a child of a wsmux at this point as it
operates on its own event queue.
2. A device being a child of a wsmux must use the wsmux event queue
assuming the wsmux is open. Otherwise, its event queue must be NULL.
There's a race in wsmux_attach_sc() allowing a device to be part of a
mux while using its own event queue. This in turn can cause a NULL
pointer deference in wsevent_fini() while closing the same device. The
solution is to check if the race was lost, i.e. another thread managed
to open the device in rw mode while sleeping in wsmux_attach_sc().
ok gnezdo@ visa@
Reported-by: syzbot+684707f0312345a090ef@syzkaller.appspotmail.com
|
|
ok kn@
|
|
many POWER8 and POWER9 systems.
|
|
|
|
proper BSD way where the third argument is always a pointer and data is
transferred between userland and kernel using copyin(9) and copyout(9).
Intead an int is encoded in the thirs argument. This works on 32-bit
architectures and little-endian 64-bit architectures. But not on
big-endian 64-bit architectures. Deal with this by handling the argument
as long (which matches the size of a pointer).
Hopefully we can eliminate these ioctls in the near future.
ok deraadt@
|
|
it back to tty*0.
This is needed to restore working defaults in wsfontload(8).
OK jcs@, mpi@
|
|
NULL. This one is a race caused by clearing the me_evp member before
calling routines that could end up sleeping.
While here, make wsmux_mux_close() look more like the other mux close
routines for increased symmetry.
ok mpi@
Reported-by: syzbot+fb9ad34ba42994683850@syzkaller.appspotmail.com
|
|
conversion steps). it only contains kernel prototypes for 4 interfaces,
all of which legitimately belong in sys/systm.h, which are already included
by all enqueue_randomness() users.
|
|
miod explained it was initially a long as it was thought drivers may
need to allocate storage but in practice they don't need more than
32 bits for an attribute.
suggested and reviewed by miod@
|
|
Suggested by John Carmack. miod agrees a rename would make sense and
explained it was initially thought drivers may need to allocate storage
but in practice they don't need more than 32 bits for an attribute.
ok mpi@
|
|
johnc@armadilloaerospace.com and another one spotted by matthieu@.
ok benno@, matthieu@, deraadt@
|
|
CID 1452993 (BUFFER_SIZE_WARNING)
CID 1453314 (BUFFER_SIZE_WARNING)
ok kettenis@
|
|
CID 1453143
ok kettenis@
|
|
into wsdisplay(4). This code is now exposed through
wsdisplay_brightness_{step,zero,cycle} functions that can be called by
any driver that handles brightnes "hotkeys". These functions take
a wsdisplay(4) device pointer as their first argument, which should be
provided if a clear association between events and a particular display
exist. This is used in wskbd(4). Otherwise NULL can be passed and
the code will direct the request at the first wsdisplay(4) that
implements brightness adjustment.
Tested by many. Fixes brightness keys on x395 and other thinkpads with
AMD graphics.
ok patrick@
|
|
for example, with locking assertions.
OK mpi@, anton@
|
|
|
|
wsmouseopen(); bringing them closer to wsmuxopen(). No functional
change.
|
|
convention for the open routine. This increases the consistency between
wskbd, wsmouse and wsmux.
|
|
devices. This condition is checked early on during open but since the
same routine could end up sleeping before assigning me_evp, a race
against adding the same wscons device to a wsmux could be lost. This in
turn can cause a NULL deference during close.
ok mpi@
Reported-by: syzbot+34c3041bfd96c888c8bd@syzkaller.appspotmail.com
|
|
CID 1453207 (Missing break in switch)
|
|
|
|
ok patrick@, jsg@
|
|
adding more filter properties without cluttering the struct.
OK mpi@, anton@
|
|
FIOGETOWN/SIOCGPGRP/TIOCGPGRP. Do this by determining the meaning of
the ID parameter inside the sigio code. Also add cases for FIOSETOWN
and FIOGETOWN where there have been TIOCSPGRP and TIOCGPGRP before.
These changes allow removing the ID translation from sys_fcntl() and
sys_ioctl().
Idea from NetBSD
OK mpi@, claudio@
|
|
make the structs const so that the data are put in .rodata.
OK mpi@, deraadt@, anton@, bluhm@
|
|
OK ratchov@, visa@
|
|
ok deraadt@, jsg@
|
|
Do not switch from the DETECT state to IGNORE when the last (active) touch
has been released. Otherwise, depending on how events are reported and
synchronized, it may happen that the handler does not switch back to DETECT
when necessary.
|
|
ok patrick@
|
|
|
|
Trivial conversion from ticks to milliseconds where macros already come in
milliseconds and timeout values only need reduction by hz to use the new API.
OK mpi
|
|
determine if the device was opened in read/write mode.
ok mpi@ visa@
|
|
function name in order to reduce grep noise. Also, some of them where referring
to the wrong function.
|
|
after checking for exclusive access, malloc() can sleep in
wsevent_init() opening up for a potential race where more than one
thread may be able open the device. Prevent this by checking if the race
was won after calling malloc().
While here, switch to mallocarray as proposed by both cheloha@ and mpi@
ok mpi@
|
|
previous commit message:
In wsmuxclose(), use the same logic as in wsmuxopen() to determine if
the device was opened in write-only mode. Relying on me_evar being NULL
does not work if the wsmux device was opened first followed attaching it
to another wsmux. Closing the wsmux device first at this stage would
cause the wscons_event queue inherited from the parent wsmux to be
freed. This in turn could cause a panic if an ioctl(WSMUXIO_INJECTEVENT)
command is issued on parent wsmux device.
ok mpi@ visa@
Reported-by: syzbot+f6c2ed7901eb4b970720@syzkaller.appspotmail.com
|
|
OK deraadt@
|
|
when we have a serial console by introducing the notion of a "primary"
graphics device. The primary graphics device is the one set up and
used by firmware (BIOS, UEFI).
The goal is to make sure that wsdisplay0 and drm0 reliably attach to
the primary graphics device such that X works out of the box even
if you have multiple cards or if you are using a serial console.
This also fixes the situation where inteldrm(4) or radeondrm(4) would
take over the console on UEFI systems even if the kernel was booted
with a serial console.
ok jsg@
|