> I have just upgraded to FreeBSD-Current, from FreeBSD-4.3 Release and
>have a problem getting my mouse working again. I did the buildworld,
>installworld, buildkernel, installkernel, etc and everything seems fine,
>except for my mouse daemon not working anymore
>
> Could someone tell me how
As far as I understand, this feature works only if the machine does not
clear its memory upon reboot. AT compatibles clear memory during the
BIOS POST, thus, we don't see console log from the previous boot
on the i386 platform.
Kazu
>sorry if that came across a bit rough...
>I just know that I L
syscons dosn't automatically switch vtys if the keyboard is not in the
XLATE mode. (Oh well, this isn't documented in vgl(3), *sigh*)
In CODEKEYS and RAWKEYS modes, you need to initiate vty switching
by yourself, by calling the ioctl VT_ACTIVATE when a key combination
for vty switching is seen.
>On Tue, Jan 09, 2001 at 05:32:29PM +0900, Kazutaka YOKOTA wrote:
>> syscons is already capable of changing forground and background colors
>> via escape sequences. Is it not sufficient for your intended
>> application?
>>
>> Kazu
>>
>
>Since I re
syscons is already capable of changing forground and background colors
via escape sequences. Is it not sufficient for your intended
application?
Kazu
>Hi,
>
>I'm thinking of messing with the syscons ioctl handler to allow setting
>of color values - all EGA- and VGA-compatible video controllers
There is a workaround, if not a fix, for this problem in -CURRENT.
Apply the following patch to /sys/isa/psm.c and add flags 0x8000
to psm driver in your kernel config file as follows.
device psm0at atkbdc? irq 12 flags 0x8000
Kazu
>I have an intermittent (and fairly rare) problem
>So, question: is there a reason why we can't enable both the USB keyboard
>and a native PS/2 keyboard with syscons? It seems that I frequently find
>myself in a position where I'd like to plug in a keyboard, or switch KVM
>choices to a machine, and discover myself with no access to the hardware
>Do you know if this fixes the problem the following problem that I started
>experiencing somewhere in the RELENG_4 line? For some machines, if the
>KVM is not pointed at the box, the keyboard will not probe properly, and
>does not respond for that session. As long as I boot with the KVM pointe
>suddenly, the console keyboard does no longer work. kdm is displayed,
>but no keypress works (except num lock and scroll lock, which light the
>appropriate LEDs).
This means your hardware (keyboard and keyboard controller) and
FreeBSD kernel (keyboard drivver) are working ok.
When in X, the ke
>> Um, may be my wording was not appropriate. I didn't mean dynamic or
>> active scanning of devices. Rather, I just wanted to have a routine
>> to enlist PnP device instances hanging from the ISA bus, so that the
>> hinted device will abondan its probe if there is a PnP
>> sibling; no active s
>> This is to propose a new ISA bus method to sys/isa/isa_common.c.
>> The new method is to enumerate PnP device instances matching the
>> specified PnP IDs. (Well, may be this is a kludge after all.)
>>
>> device_t ISA_PNP_SCAN(device_t bus, struct isa_pnp_id *ids, int *n);
>>
>> It will retur
This is to propose a new ISA bus method to sys/isa/isa_common.c.
The new method is to enumerate PnP device instances matching the
specified PnP IDs. (Well, may be this is a kludge after all.)
device_t ISA_PNP_SCAN(device_t bus, struct isa_pnp_id *ids, int *n);
It will return the (n + 1)th instan
>Hi!
>
>I have a 3-button microsoft-type serial mouse (I do not know the vendor,
>only FCC ID if needed) which generates the `middle button down' event as
>previous `button down/up' event (any). Attached are:
I have heard about this tipe of mouse. It's one of old serial mice,
isn't it?
>1. th
>> Much more distressing: if I switch out of X to a text mode console with
>> Ctrl-Alt-Fn, and then switch back to X, the machine freezes up
>> completely and has to be power-cycled. It does first switch back into
>> graphics mode, and I can see the top part of the screen is messed up, so
>> it ha
>I am running 4.0-S on a Compaq Presario laptop with a Trident Cyberblade
>VGA. I couldn't get this to work in anything other than 640x480 with
>XFree86-3.3.6, so I moved to XFree86-4.0 (and no, I'm not interested in
>mail from people who say that the Trident Cyberblade works for them in
>3.3.6; b
>In message <[EMAIL PROTECTED]>
>"Chris D. Faulhaber" writes:
>: Since this has been brought up, any reason that BROKEN_KEYBOARD_RESET is
>: not a recognized option (see kern/12927)?
>
>Likely fell through the cracks when Eivind made everything an option.
>If it didn't, then someone likely broke
>I have a freebsd system(3.4S) on a KVM and every time the monitored
>system is switched, the mouse driver gets fuxored, and when you switch
>back to the system the driver starts outputting oodles of the following
>messages to syslog every time the mouse is moved:
>
>Apr 26 18:49:45 kyxbot /ke
>On Fri, 7 Apr 2000, Kazutaka YOKOTA wrote:
>
>> Multilingual text processing in the userland is a completely different
>> issue which, I think, should be discussed separately.
>
> I agree with this completely. The question is, where?
I didn't say this mailing
>I have suggested adding Unicode support in the keyboard driver and the
>vga driver (more precisely, vga and syscons). As a result of such changes:
>
>a) keymap files would map keycodes to the desired Unicode values rather
>than 8-bit values depending on a particular encoding, which should
>great
>> The word at 0x463 in the BIOS data area tells at which I/O address the
>> CRTC is sitting on. It's 0x3b4 for the monochrome adapter and EGA/VGA
>> in a monochrome mode, and 0x3d4 for CGA and EGA/VGA in a color mode.
>>
>> So, we should try to set the mode 3 when we find 0x3d4 and the mode 7
>
>There is a way to detect monochrome or color via one of the 0x3dX registers.
>It's the register that tells you if the rest of the vido registers are at 0x3b
>X
>(mono) or 0x3cX (color). I can't remember which bit in which register that is
>though. If someone can find that out, then we can fix
>I have the Logitech wireless radio mouse, and I get errors about illegal or
>unknown PS/2 packets. It's cosmetic, because the mouse works like a charm,
>but the very first mouse click or move makes it jump across the screen.
>After that
Please provide the following information so that I can diag
for 4.0-CURRENT
24 January 2000
Kazutaka YOKOTA, [EMAIL PROTECTED]
This patch adds support for the following PS/2 mice to the psm driver.
- Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons
and a wheel which also acts as the middle button.
- Genius NetScroll Optical: 2 buttons
>Kazutaka> This is pretty wiered. You mean the REAL left ALT key
>Kazutaka> doesn't work on this notebook and the external keyboard?
>
>The left ALT does *something*, I just don't know what (yet). To get
>the standard left ALT behaviour I have to use the "windows" key.
In what environme
>> Nearly everyone who wants to set up their national locale
>> needs to recompile the kernel, since some important characters
>> are hidden under mouse cursor.
>
>I agree with you - it is very strange for Czech users too (and maybe
>for almost all ISO-8859-* users) - default mouse settings overr
Hi,
>Failing that, has anyone figured out a keyboard mapping for an
>Inspiron 7000 that puts the left ALT key back where it belongs?
>(The reason for the first request is to try to determine what
>effect the left ALT key actually has. On this laptop, the "windows"
>key does what left ALT normally
>A few days ago I was at Office Max and bought an InterAct "Web.Remote
>professional". For those of you who don't know, its an infrared
>remote control which contains a trackball, two trackball buttons, and
>an 18-key keypad. It was a pretty good deal for $17US.
>
>My ultimate goal is to use it
I just wonder why don't we just import termcap database from
the master site: http://www.tuxedo.org/terminfo, rather than
maintaining our own copy?
In the past, it has been pointed out that some of the termcap entries
needs updating. Some entries have been revised. But, it appears that
some oth
>> He wanted a to be able to panic() a machine from console without being
>> able to drop to DDB from console. I think this is because he believes
>> that DDB is a security problem. :-)
>
>Well, I'm missing something: the beginning of this thread, so this may
>not be 100% relevant, but I've just
>>Number: 13721
>>Category: kern
>>Synopsis: There is no way to force system panic from console
[...]
>>Release:FreeBSD 3.3-RC
>>Organization:
>Server
>>Environment:
>>Description:
>Under some rare circumstances there is a real need to reboot system via kernel
>'s panic
>>Number: 13721
>>Category: kern
>>Synopsis: There is no way to force system panic from console
[...]
>>Release:FreeBSD 3.3-RC
>>Organization:
>Server
>>Environment:
>>Description:
>Under some rare circumstances there is a real need to reboot system via kernel
>'s pani
> Tonight while testing my rc file changes I decided to interrupt the spl
>ash
>screen display I have to see the boot messages. I hit scroll lock to do
>this, and it killed the splash screen, but when I went to log in the
>keyboard on the console was pretty much fubar. Every key was mapped t
> Tonight while testing my rc file changes I decided to interrupt the spl
>ash
>screen display I have to see the boot messages. I hit scroll lock to do
>this, and it killed the splash screen, but when I went to log in the
>keyboard on the console was pretty much fubar. Every key was mapped
># The keyboard controller; it controls the keyboard and the PS/2 mouse.
>controller atkbdc0 at isa? port IO_KBD tty
>device atkbd0 at atkbdc? irq 1
~~~ -> isa?
>device psm0at isa? disable tty irq 12
>device vga0at isa? port ? co
># The keyboard controller; it controls the keyboard and the PS/2 mouse.
>controller atkbdc0 at isa? port IO_KBD tty
>device atkbd0 at atkbdc? irq 1
~~~ -> isa?
>device psm0at isa? disable tty irq 12
>device vga0at isa? port ? c
>> I am attempting to get FreeBSD 3.2 and/or 4.0 to go on a TP 360c. The
>> problem I am having is that the keyboard works all the way up to sysinstall.
>> I can use the keyboard in the visual kernel config/etc. I searched and foun
>d
>> under 2.2 they suggested setting flags 0x10 on syscons.
>> I am attempting to get FreeBSD 3.2 and/or 4.0 to go on a TP 360c. The
>> problem I am having is that the keyboard works all the way up to sysinstall.
>> I can use the keyboard in the visual kernel config/etc. I searched and foun
>d
>> under 2.2 they suggested setting flags 0x10 on syscons.
>> In FreeBSD version 3.1 or later, the keyboard controller atkbdc(4) and
>> AT keyboard driver atkbd(4) will give you access to the keyboard even
>> when there is no video card.
> Thanks, I read the source and found the CDEV stuff... I had to
>disable the sc0 device to get access to it. a
>> In FreeBSD version 3.1 or later, the keyboard controller atkbdc(4) and
>> AT keyboard driver atkbd(4) will give you access to the keyboard even
>> when there is no video card.
> Thanks, I read the source and found the CDEV stuff... I had to
>disable the sc0 device to get access to it.
> I am working on an embedded server, and have run into some
>difficulty. I need to access the keyboard (to read keys) on a machine
>that has no video. (no video card, that is)
> I wrote a program that works fine when run from the shell prompt
>(working with stdin)... but this is
> I am working on an embedded server, and have run into some
>difficulty. I need to access the keyboard (to read keys) on a machine
>that has no video. (no video card, that is)
> I wrote a program that works fine when run from the shell prompt
>(working with stdin)... but this is
>Is there a plan for how to access the linear framebuffer in VESA video
>modes? So far as I can tell, the current[1] VESA code doesn't support
>enabling the linear framebuffer access at all, even though "vidcontrol -i
>mode" is happy to tell you the details of the buffers that you can't get
>acce
>Is there a plan for how to access the linear framebuffer in VESA video
>modes? So far as I can tell, the current[1] VESA code doesn't support
>enabling the linear framebuffer access at all, even though "vidcontrol -i
>mode" is happy to tell you the details of the buffers that you can't get
>acc
The second draft of the serial console section in the FreeBSD handbook
is ready. It is available at the same URL as below.
Please review and correct any technical, grammatical, or whatever
errors.
Thank you.
Kazu
>>From time to time people ask questions about the serial console. As
>README.s
The second draft of the serial console section in the FreeBSD handbook
is ready. It is available at the same URL as below.
Please review and correct any technical, grammatical, or whatever
errors.
Thank you.
Kazu
>>From time to time people ask questions about the serial console. As
>README.
>I'm trying to get a 3.2-STABLE to boot via the serial console.
>
>I can get the "boot: " rompt and loader to display to the serial
>console, but after the 9 second delay it continues to boot but
>no output is generated to the screen (device probes etc.).
>
>After the boot has completed, the login
>I'm trying to get a 3.2-STABLE to boot via the serial console.
>
>I can get the "boot: " rompt and loader to display to the serial
>console, but after the 9 second delay it continues to boot but
>no output is generated to the screen (device probes etc.).
>
>After the boot has completed, the login
>From time to time people ask questions about the serial console. As
README.serial is buried deep inside the kernel source tree, it's almost
time to have a decent text on the serial console in our handbook.
I am reformatting README.serial so that it can be included in our
handbook, and adding bi
>> Are you sure you enabled "options VM86" in the kernel configuration
>> file and loaded the vesa module by the boot loader?
>Hmmm ...
>When I added "options VM86" to my kernel config file I get:
>
>su-2.02# config BANTU
>BANTU:135: unknown option "VM86"
>Unknown option used - it is VERY importan
>> 3. The video card doesn't support required graphics modes.
>>Run 'vidcontrol -i mode' and see if the 320x200 256 color mode
>>is supported. The vga driver in FreeBSD may not be able to support
>>all video modes, if the video card's BIOS is not as compatible as
>>it should be.
>This morning I tried to boot that kernel. It comes up, but the console
>is dead! The DISPLAY is ok, but I have no keyboard control. Replugging
>the keyboard does not help.
>
>Here's the boot trace... (with a bit of annotation)
>
>Copyright (c) 1992-1999 The FreeBSD Project.
>Copyright (c) 1982,
>> On a slightly related note, I am currently in the process of developing
>> patches to add more useful "tweaked" modes to the video driver:
>> graphics 720x480, 16 colors (90x30 8x16 character cells)
>> graphics 256x256, 256 colors (32x32 8x8 character cells)
>> graphics 296x220, 256
> I think you just nailed the problem here. It requires a prohibitive
>amount of effort to support modex video modes given the return. What I am
>thinking about is removing the 320x240 mode (since it is impossibly
>difficult to deal with)...no one is using it now so no one would be
>affected. I wo
>> In that sense, the support for 320x240 mode-X is minimal too. The
>> driver can set up this mode, but has no knowledge or code to write to
>> it. It is entirely up to the userland program to update the video
>> buffer. (And it is true that there is very little use to this mode at
>> the mome
Sorry for not participating in your earlier discussion, I have been
kept busy by my work ;-<
The current VGA driver code won't do much in the graphics mode. It
simply switches to a graphics mode when requested, but it has no code
to actually write anything to the video buffer in the graphics mode
56 matches
Mail list logo
