History log of /freebsd/sys/dev/syscons/syscons.h (Results 176 – 200 of 275)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 8d521790 23-Feb-2010 Jung-uk Kim <jkim@FreeBSD.org>

Yet another attempt to make palette loading more safer:

- Add a separate palette data for 8-bit DAC mode when SC_PIXEL_MODE is set
and fill it up with default gray-scale palette data for text. Now

Yet another attempt to make palette loading more safer:

- Add a separate palette data for 8-bit DAC mode when SC_PIXEL_MODE is set
and fill it up with default gray-scale palette data for text. Now we don't
have to set `hint.sc.0.vesa_mode' to get the default palette data.
- Add a new adapter flag, V_ADP_DAC8 to track whether the controller is
using 8-bit palette format and load correct palette when switching modes.
- Set 8-bit DAC mode only for non-VGA compatible graphics mode.

show more ...


Revision tags: release/8.0.0_cvs, release/8.0.0
# 874108ae 12-Nov-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

MFC @199204


# 3a8a07ea 11-Nov-2009 Ed Schouten <ed@FreeBSD.org>

Allow Syscons terminal emulators to provide function key strings.

xterm and cons25 have some incompatibilities when it comes to escape
sequences for special keys, such as F1 to F12, home, end, etc.

Allow Syscons terminal emulators to provide function key strings.

xterm and cons25 have some incompatibilities when it comes to escape
sequences for special keys, such as F1 to F12, home, end, etc. Add a new
te_fkeystr() that can be used to override the strings.

scterm-sck won't do anything with this, but scterm-teken will use
teken_get_sequences() to obtain the proper sequence.

show more ...


# 1ee774f6 02-Oct-2009 Oleksandr Tymoshenko <gonzo@FreeBSD.org>

- MFC


# 53e69c0c 27-Sep-2009 Ed Schouten <ed@FreeBSD.org>

Add support for VT200-style mouse input.

Right now if applications want to use the mouse on the command line,
they use sysmouse(4) and install a signal handler in the kernel to
deliver signals when

Add support for VT200-style mouse input.

Right now if applications want to use the mouse on the command line,
they use sysmouse(4) and install a signal handler in the kernel to
deliver signals when mouse events arrive. This conflicts with my plan to
change to TERM=xterm, so implement proper VT200-style mouse input.

Because mouse input is now streamed through the TTY, it means you can
now SSH to another system on the console and use the mouse there as
well. The disadvantage of the VT200 mouse protocol, is that it doesn't
seem to generate events when moving the cursor. Only when pressing and
releasing mouse buttons.

There are different protocols as well, but this one seems to be most
commonly supported.

Reported by: Paul B. Mahol <onemda gmail com>
Tested with: vim(1)

show more ...


# 493d6f54 11-Sep-2009 Xin LI <delphij@FreeBSD.org>

Extend the usage of sc(4)'s hint variable 'flag'. Bit 0x80 now means
"set vesa mode" and higher 16bits of the flag would be the desired mode.

One can now set, for instance, hint.sc.0.flags=0x016801

Extend the usage of sc(4)'s hint variable 'flag'. Bit 0x80 now means
"set vesa mode" and higher 16bits of the flag would be the desired mode.

One can now set, for instance, hint.sc.0.flags=0x01680180, which means
that the system should set VESA mode 0x168 upon boot.

Submitted by: paradox <ddkprog yahoo com>, swell k at gmail.com with
some minor changes.

show more ...


Revision tags: release/7.2.0_cvs, release/7.2.0
# 1829d5da 12-Mar-2009 Warner Losh <imp@FreeBSD.org>

Update the projects tree to a newer FreeBSD current.


# 630b9bf2 10-Mar-2009 Ed Schouten <ed@FreeBSD.org>

Make a 1:1 mapping between syscons stats and terminal emulators.

After I imported libteken into the source tree, I noticed syscons didn't
store the cursor position inside the terminal emulator, but

Make a 1:1 mapping between syscons stats and terminal emulators.

After I imported libteken into the source tree, I noticed syscons didn't
store the cursor position inside the terminal emulator, but inside the
virtual terminal stat. This is not very useful, because when you
implement more complex forms of line wrapping, you need to keep track of
more state than just the cursor position.

Because the kernel messages didn't share the same terminal emulator as
ttyv0, this caused a lot of strange things, like kernel messages being
misplaced and a missing notification to resize the terminal emulator for
kernel messages never to be resized when using vidcontrol.

This patch just removes kernel_console_ts and adds a special parameter
to te_puts to determine whether messages should be printed using regular
colors or the ones for kernel messages.

Reported by: ache
Tested by: nyan, garga (older version)

show more ...


# b4b1c516 01-Jan-2009 Ed Schouten <ed@FreeBSD.org>

Replace syscons terminal renderer by a new renderer that uses libteken.

Some time ago I started working on a library called libteken, which is
terminal emulator. It does not buffer any screen conten

Replace syscons terminal renderer by a new renderer that uses libteken.

Some time ago I started working on a library called libteken, which is
terminal emulator. It does not buffer any screen contents, but only
keeps terminal state, such as cursor position, attributes, etc. It
should implement all escape sequences that are implemented by the
cons25 terminal emulator, but also a fair amount of sequences that are
present in VT100 and xterm.

A lot of random notes, which could be of interest to users/developers:

- Even though I'm leaving the terminal type set to `cons25', users can
do experiments with placing `xterm-color' in /etc/ttys. Because we
only implement a subset of features of xterm, this may cause
artifacts. We should consider extending libteken, because in my
opinion xterm is the way to go. Some missing features:

- Keypad application mode (DECKPAM)
- Character sets (SCS)

- libteken is filled with a fair amount of assertions, but unfortunately
we cannot go into the debugger anymore if we fail them. I've done
development of this library almost entirely in userspace. In
sys/dev/syscons/teken there are two applications that can be helpful
when debugging the code:

- teken_demo: a terminal emulator that can be started from a regular
xterm that emulates a terminal using libteken. This application can
be very useful to debug any rendering issues.

- teken_stress: a stress testing application that emulates random
terminal output. libteken has literally survived multiple terabytes
of random input.

- libteken also includes support for UTF-8, but unfortunately our input
layer and font renderer don't support this. If users want to
experiment with UTF-8 support, they can enable `TEKEN_UTF8' in
teken.h. If you recompile your kernel or the teken_demo application,
you can hold some nice experiments.

- I've left PC98 the way it is right now. The PC98 platform has a custom
syscons renderer, which supports some form of localised input. Maybe
we should port PC98 to libteken by the time syscons supports UTF-8?

- I've removed the `dumb' terminal emulator. It has been broken for
years. It hasn't survived the `struct proc' -> `struct thread'
conversion.

- To prevent confusion among people that want to hack on libteken:
unlike syscons, the state machines that parse the escape sequences are
machine generated. This means that if you want to add new escape
sequences, you have to add an entry to the `sequences' file. This will
cause new entries to be added to `teken_state.h'.

- Any rendering artifacts that didn't occur prior to this commit are by
accident. They should be reported to me, so I can fix them.

Discussed on: current@, hackers@
Discussed with: philip (at 25C3)

show more ...


Revision tags: release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0
# bc093719 20-Aug-2008 Ed Schouten <ed@FreeBSD.org>

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve

Integrate the new MPSAFE TTY layer to the FreeBSD operating system.

The last half year I've been working on a replacement TTY layer for the
FreeBSD kernel. The new TTY layer was designed to improve the following:

- Improved driver model:

The old TTY layer has a driver model that is not abstract enough to
make it friendly to use. A good example is the output path, where the
device drivers directly access the output buffers. This means that an
in-kernel PPP implementation must always convert network buffers into
TTY buffers.

If a PPP implementation would be built on top of the new TTY layer
(still needs a hooks layer, though), it would allow the PPP
implementation to directly hand the data to the TTY driver.

- Improved hotplugging:

With the old TTY layer, it isn't entirely safe to destroy TTY's from
the system. This implementation has a two-step destructing design,
where the driver first abandons the TTY. After all threads have left
the TTY, the TTY layer calls a routine in the driver, which can be
used to free resources (unit numbers, etc).

The pts(4) driver also implements this feature, which means
posix_openpt() will now return PTY's that are created on the fly.

- Improved performance:

One of the major improvements is the per-TTY mutex, which is expected
to improve scalability when compared to the old Giant locking.
Another change is the unbuffered copying to userspace, which is both
used on TTY device nodes and PTY masters.

Upgrading should be quite straightforward. Unlike previous versions,
existing kernel configuration files do not need to be changed, except
when they reference device drivers that are listed in UPDATING.

Obtained from: //depot/projects/mpsafetty/...
Approved by: philip (ex-mentor)
Discussed: on the lists, at BSDCan, at the DevSummit
Sponsored by: Snow B.V., the Netherlands
dcons(4) fixed by: kan

show more ...


Revision tags: release/7.0.0_cvs, release/7.0.0
# 1d9c3ad3 14-Feb-2008 John Baldwin <jhb@FreeBSD.org>

Mark the syscons video spin mutex as recursable since it is currently
recursed in a few places.

MFC after: 1 week


Revision tags: release/6.3.0_cvs, release/6.3.0
# 259699b2 29-Dec-2007 Wojciech A. Koszek <wkoszek@FreeBSD.org>

Remove explicit calls to keyboard methods with their respective variants
implemented with macros. This patch improves code readability. Reasoning
behind kbdd_* is a "keyboard discipline".

List of ma

Remove explicit calls to keyboard methods with their respective variants
implemented with macros. This patch improves code readability. Reasoning
behind kbdd_* is a "keyboard discipline".

List of macros is supposed to be complete--all methods of keyboard_switch
should have their respective macros from now on.

Functionally, this code should be no-op. My intention is to leave current
behaviour of code as is.

Glanced at by: rwatson
Reviewed by: emax, marcel
Approved by: cognet

show more ...


# a69d19dc 20-Sep-2007 Hidetoshi Shimokawa <simokawa@FreeBSD.org>

Serialize output routine of terminal emulator (te_puts()) by a lock.
- The output routine of low level console is not protected by any lock
by default.
- Increment and decrement of sc->write_in_progr

Serialize output routine of terminal emulator (te_puts()) by a lock.
- The output routine of low level console is not protected by any lock
by default.
- Increment and decrement of sc->write_in_progress are not atomic and
this may cause console hang.
- We also have many other states used by emulator that should be protected
by the lock.
- This change does not fix interspersed messages which PRINTF_BUFR_SIZE
kernel option should fix.

Approved by: re (bmah)
MFC after: 1 week

show more ...


Revision tags: release/6.2.0_cvs, release/6.2.0
# 988129b8 13-Sep-2006 Scott Long <scottl@FreeBSD.org>

Introduce a spinlock for synchronizing access to the video output hardware
in syscons. This replaces a simple access semaphore that was assumed to be
protected by Giant but often was not. If two th

Introduce a spinlock for synchronizing access to the video output hardware
in syscons. This replaces a simple access semaphore that was assumed to be
protected by Giant but often was not. If two threads that were otherwise
SMP-safe called printf at the same time, there was a high likelyhood that
the semaphore would get corrupted and result in a permanently frozen video
console. This is similar to what is already done in the serial console
drivers.

show more ...


Revision tags: release/5.5.0_cvs, release/5.5.0
# 73dbd3da 12-May-2006 John Baldwin <jhb@FreeBSD.org>

Remove various bits of conditional Alpha code and fixup a few comments.


Revision tags: release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0
# b7c96c0d 28-Sep-2005 Marius Strobl <marius@FreeBSD.org>

Add a font width argument to vi_load_font_t, vi_save_font_t and vi_putm_t
and do some preparations for handling 12x22 fonts (currently lots of code
implies and/or hardcodes a font width of 8 pixels).

Add a font width argument to vi_load_font_t, vi_save_font_t and vi_putm_t
and do some preparations for handling 12x22 fonts (currently lots of code
implies and/or hardcodes a font width of 8 pixels). This will be required
on sparc64 which uses a default font size of 12x22 in order to add font
loading and saving support as well as to use a syscons(4)-supplied mouse
pointer image.
This API breakage is committed now so it can be MFC'ed in time for 6.0
and later on upcoming framebuffer drivers destined for use on sparc64
and which are expected to rely on using font loading internally and on
a syscons(4)-supplied mouse pointer image can be easily MFC'ed to
RELENG_6 rather than requiring a backport.

Tested on: i386, sparc64, make universe
MFC after: 1 week

show more ...


# 86330afe 30-Aug-2005 Craig Rodrigues <rodrigc@FreeBSD.org>

Prevent division by zero errors in sc_mouse_move()
by explicitly setting sc->font_width, in the same
places where sc->font_size is set, instead of
relying on the default initialized value of 0 for sc

Prevent division by zero errors in sc_mouse_move()
by explicitly setting sc->font_width, in the same
places where sc->font_size is set, instead of
relying on the default initialized value of 0 for sc->font_width.

PR: kern/84836
Reported by: Andrey V. Elsukov <bu7cher at yandex dot ru>
MFC after: 2 days

show more ...


# f1121206 29-May-2005 Xin LI <delphij@FreeBSD.org>

Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA sup

Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.

Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.

Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.

Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]

show more ...


# fc0e49bd 21-May-2005 Marius Strobl <marius@FreeBSD.org>

On sparc64 use 'syscons' rather than 'sc' for SC_DRIVER_NAME so
syscons(4) and its pseudo-devices don't get confused (including by
other device drivers) with the system controller devices which are
a

On sparc64 use 'syscons' rather than 'sc' for SC_DRIVER_NAME so
syscons(4) and its pseudo-devices don't get confused (including by
other device drivers) with the system controller devices which are
also termed 'sc' in the OFW tree (and which we probably want to
interface with hwpmc(4) one day).

show more ...


# d1725ef7 10-May-2005 Yoshihiro Takahashi <nyan@FreeBSD.org>

Change a directory layout for pc98.
- Move MD files into <arch>/<arch>.
- Move bus dependent files into <arch>/<bus>.
Rename some files to more suitable names.

Repo-copied by: peter
Discussed wi

Change a directory layout for pc98.
- Move MD files into <arch>/<arch>.
- Move bus dependent files into <arch>/<bus>.
Rename some files to more suitable names.

Repo-copied by: peter
Discussed with: imp

show more ...


Revision tags: release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0
# 1f744902 28-Jul-2004 Alexander Kabaev <kan@FreeBSD.org>

Avoid casts as lvalues.


# 3e019dea 15-Jul-2004 Poul-Henning Kamp <phk@FreeBSD.org>

Do a pass over all modules in the kernel and make them return EOPNOTSUPP
for unknown events.

A number of modules return EINVAL in this instance, and I have left
those alone for now and instead taugh

Do a pass over all modules in the kernel and make them return EOPNOTSUPP
for unknown events.

A number of modules return EINVAL in this instance, and I have left
those alone for now and instead taught MOD_QUIESCE to accept this
as "didn't do anything".

show more ...


# 89c9c53d 16-Jun-2004 Poul-Henning Kamp <phk@FreeBSD.org>

Do the dreaded s/dev_t/struct cdev */
Bump __FreeBSD_version accordingly.


Revision tags: release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0
# 73b0c907 24-Aug-2003 Jake Burkholder <jake@FreeBSD.org>

- Add a font width field to struct scr_stat. Use this instead of '8'.
- Use the values in the video info for the font size and width instead
of second guessing.


# 8b9698b7 24-Aug-2003 Jake Burkholder <jake@FreeBSD.org>

Add sparc64 ifdefs.


1234567891011