- Only A1416 Kathmandu (topcat) framebuffer on 425t is tested, but
all other variants (TigerShark, Hyperion, DaVinci, GatorBox, Renaissance)
should also work if they are working on OpenBSD/hp300.
- sti(4) and SGC bus support are not pulled because I don't have 425e
and I can't confirm that 362 and 382 actually have SGC bus.
(I'll commit a DIO based dumb driver for 362 and 382 framebuffers later)
- Xorg server with wsfb driver will also be integrated soon
once after keycode with NoSymbol problem is addressed.
(We have to re-think what code should be used on WSDISPLAY_COMPAT_RAWKBD)
- MI HIL keyboard and mouse drivers are working fine though
cngetc via hilkbd has some problem (still we can input commands).
- No old HP-UX like HIL ioctl compatibility (we removed COMPAT_HPUX anyway).
grfinfo(8) and hilinfo(8) will be removed shortly.
Demonstrated on NetBSD booth at Open Source Conference 2011 Kagawa.
This is not finished but good enough for others to play with, enable with
options VCONS_DRAW_ASYNC
With this all drawing operations will be posted to a ring buffer instead
of being run directly, and run by a kernel thread. This avoids having to wait
for drawing operations to finish with the kernel lock held ( to a degree at
least ) and scrolling a (slow) framebuffer console should not disrupt other
operations anymore.
Problems:
- we need to switch back to synchronous operations when panicing or entering
ddb, also re-enable async drawing when leaving ddb
- there are still occasional glitches
tested on an SS20 with cg14 and cg6 for dumb and accelerated cases
It returns the bus id and allows userland (like Xorg) to create mapping
of ttyE? and bus id. For now only PCI is implemented.
First discussed with macallan@ then public on tech-kern@ and tech-x11@
XXX: This is kind of futile; the only user of the wskbd(4)'s hotkey interface
is hpqlb(4), which is a questionable driver, being, by design,
limited only to the laptop model for which the driver was written.
driver methods, call the driver's putchar() method to redraw the affected
areas.
For unaccelerated framebuffers where reads are expensive and we can't spare
any memory for a shadow framebuffer. Enabled by setting VCONS_DONT_READ in
scr_flags
Rename real routines to proc_find() and pgrp_find(), remove PFIND_* flags
and have consistent behaviour. Provide proc_find_raw() for special cases.
Fix memory leak in sysctl_proc_corename().
COMPAT_LINUX: rework ptrace() locking, minimise differences between
different versions per-arch.
Note: while this change adds some formal cosmetics for COMPAT_DARWIN and
COMPAT_IRIX - locking there is utterly broken (for ages).
Fixes PR/43176.
things if NWSDISPLAY is 0.
Arguably the right fix is to not allow "options WSDISPLAY_SCROLLSUPPORT"
to be enabled in this case, but AIUI config doesn't know how to encode
rules like that.
and non-const types, and the kernel uses both const and non-const
PMF qualifiers and device suspensors, so change the pmf_qual_t and
device_suspensor_t typedefs from "pointers to const" to non-pointer,
non-const types.
wsemul_vt100_subr.c) to be used by alternative terminal emulators
(which are not in-tree yet but can be loaded as LKMs).
For this, split out that part of the state structure which is used
by the sharable code and include that in the original vt100 state.
This is only a query-replace and sed(1) job for now, it makes sense
to rearrange things a bit so that even more code can be changed --
will do so later.
this is what it meant all the time -- it includes characters >127
-delegate translation of all key symbols >127 to the terminal emulation
layer -- formerly everything non-special was passed to the tty subsystem
directly, involving truncation to a "char", which effectively meant
some ISO-1 assumption
type/status/etc inquiries. (PR kern/37915)
This is clearly a design problem in tty, but we need a cheap fix now.
The problem is that ttyinput() tries to pull a spinlock which
is already held on calls to t_oproc.
The workaround is based on the fact that within wscons code, the
wsdisplay_emulinput() function is only called directly from
wsdisplaystart(). So we can be sure that the tty lock is held,
and use an inofficial entry point in ttc.c which avoids the locking.
These ate certainly more assumptions than needed by the fix
proposed in the PR, but it doesn't affect (and slow down) other
tty drivers.
jmcneill