Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >If anybody out there with a Sun serial mouse working under XFree86 4.0 and >a 2.6 kernel could send me their mouse section (as above) Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/psaux" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "false" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Since /dev/input/mice doesn't exist, obviously the first one is being used. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
David S. Miller wrote: > On 16 Mar 2005 02:48:27 + > Martin <[EMAIL PROTECTED]> wrote: > >> This: >> http://lists.debian.org/debian-sparc/2004/05/msg00203.html >> purports to be a patch, seems a bit hack-ish but looks like a start. I >> guess it's not a complete solution for the reason given here: >> http://lists.debian.org/debian-sparc/2004/01/msg00026.html > > Right, it only works when your video card is behind the > first PCI controller. > >> The latest CVS version of XFree86 seems to have a different solution >> which I /think/ solves the problem. >> http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c >> change 249 >> "249. Deal with Linux 2.6's PCI bus naming (Marc La France)." > > It looks promising. > >> But given that 4.4 won't be in Debian for licencing reasons and there is >> a migration to X.org planned for post-sarge it does seem like quite a >> reasonable approach to solving the problem. > > Right, and I'm more than happy to work on a careful backport > of that patch. > > I'll try to find some time for that. > > Thanks for this, I havnet had much time today but I implemented the hack as laid out in http://lists.debian.org/debian-sparc/2004/02/msg00013.html Now lspci and scanpci do indeed show the same output again. XFree86 -scanpci is still empty and X does not start in multihead mode: Fatal server error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices But I specified them in the XF86Config-4 and each card is working fine in a single screen layout with the data below. Section "Device" Identifier "Creator3D" Driver "sunffb" BusID "SBUS:/SUNW,[EMAIL PROTECTED],0" Option "UseFBDev" "true" Option "FBDev" "/dev/fb0" EndSection Section "Device" Identifier "Matrox Millenium" Driver "fbdev" BusID "0001:00:02.0" Option "UseFBDev" "true" Option "FBDev" "/dev/fb1" EndSection -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
| So you're saying I should use the "us" (PC104) keyboard mapping even | with the Sun type 5 keyboard on a 2.6 kernel? Let me give it a shot... Any X keymap available ? This is what I used successfully in XF86Config-4 on a 2.4.27 kernel with the system (console) keyboard mapping set to "sunkeymap": Section "InputDevice" Identifier "Sun Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "sun" Option "XkbModel" "type5" Option "XkbLayout" "us" EndSection and this is what I'm using now, on a 2.6.8 kernel with the system (console) keyboard mapping set to "us" (pc104): Section "InputDevice" Identifier "Sun Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "Device""/dev/input/event1" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection I'm pretty sure that the 2.4 kernel didn't even need a "Device" entry like the 2.6 kernel does. Or maybe I accidentally deleted it. In any case, I tried the 2.6 kernel's block with "sun" and "type5", but the key mappings were all wrong. AFAIK this might be the best one can do, but I'm the one with the questions in ths case, not the answers... The keyboard seems to be working OK now (except, as noted above by Vincent Pelletier, for a possible lack of special Sun key functionality), but I can't get the Sun serial mouse going. I tried "/dev/sunmouse", which is what the 2.4 kernel liked, as well as "/dev/input/mice" (which is what the 2.6 kernel likes for the USB mouse) and "/dev/input/mouse0" : Section "InputDevice" Identifier "Sun Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mouse0" Option "Protocol" "BusMouse" Option "Emulate3Buttons" "true" EndSection None of these work. "/dev/sunmouse" maps to no existing device, and apparently neither of the other two (existing) devices above correspond to the Sun mouse. If anybody out there with a Sun serial mouse working under XFree86 4.0 and a 2.6 kernel could send me their mouse section (as above), or if anyone could tell me what device a Sun serial mouse maps to under X, I'd be grateful. Actually, maybe the "Protocol" section might be wrong also (maybe "ImPS/2" rather than "BusMouse"?), so please correct me there if that's the case. Thanks. Dan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
> It's as though the Sun keyboard's firmware was > reprogrammed to generate PC104 scan codes. That's completely normal behavior with 2.6 kernels (where the input layer was redesigned). So you're saying I should use the "us" (PC104) keyboard mapping even with the Sun type 5 keyboard on a 2.6 kernel? Let me give it a shot... See the post-halloween-2.6.txt doc in kernel source Documentation dir. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
On Wednesday 16 March 2005 19:23, Daniel E. Jonsen wrote: > It's as though the Sun keyboard's firmware was > reprogrammed to generate PC104 scan codes. That's completely normal behavior with 2.6 kernels (where the input layer was redesigned). See the post-halloween-2.6.txt doc in kernel source Documentation dir. Cheers, FJP pgppuHwPAY3My.pgp Description: PGP signature
weird-o-rama: Type5 keyboard suddenly becomes PC104 keyboard...
I have an Ultra5 running a custom 2.6.8 kernel that I'm using as a LAMP
server. I have a PCI USB 2.0 board installed so that I can use my PC104
USB keyboard & mouse and put the Ultra5 on my 4-port USB KVM switch while I
set everything up & debug, then I'll yank the USB board and move the
machine across the building to the server room, where there's plenty of
space for the Sun type 5 keyboard & mouse. The kernel I'm running now
("USB kernel") has USB and full HID compiled-in and sun KB & mouse as
modules (not loaded). I also compiled the exact same kernel, but with Sun
keyboard & mouse compiled-in and all USB stuff as modules ("Sun
kernel"). The whole time using the USB kernel, I had to have the Sun KB
attached so that the machine wouldn't boot to a serial console, and to
interact with the OpenFirmware prompt.
I just tried booting with the Sun kernel after (using the USB kernel)
running 'dpkg-reconfigure console-data' followed by 'dpkg-reconfigure
console-common'. Using these two commands, I set the system keyboard map
to "sunkeymap", which is apparently correct for a Sun type 5 US
keyboard. After rebooting, the system took no input from the USB keyboard
and did take input from the Sun keyboard, as expected. However, what I
didn't expect was this: the keys on the sun keyboard, even with the
"sunkeymap" console mapping, generate exactly the same output as the keys
on the USB keyboard when I run it with the Sun keyboard map. It's as
though the Sun keyboard's firmware was reprogrammed to generate PC104 scan
codes. No, I'm not on drugs. And the Sun keyboard works normally at the
OpenFirmware prompt. Anyone have any clue what's causing this? Any idea
how I can fix this?
As a very slight aside, my keyboard actually has "MODEL: TYPE 6" molded
into the bottom, but it ran perfectly with the type 5 keymap before, and
I've only ever read about type 6 keyboards in USB form.
Thanks.
Dan.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Sparc Buildd
Uwe A. P. Wuerdinger schrieb: [-snip-] A big thank you to all wo have sent me pm I just ordered 2 512MB TwinMOS/SunBlade 100 Memory Module 168pin PC133 ECC SDRAM DIMM (p/n MX-X6993A) with shipping that will be < 250$ ordered from http://www.memoryx.net greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
Re: Sun Blade 100 installation
On March 15, 2005, Daniel_Lönn wrote: > "So if I download a full ISO, say > http://debian-cd.rutgers.edu/images/sparc/debian-30r1-sparc-binary-1.iso > , and burn it, I can boot from that disk and use it to do a network > install? There's not a scaled down version designed for network > install, anywhere?" > > ---> > > Of course, that's what I did. It gives a variety of install methods. Go > ahead ;-) Good luck! Thank you for your help. I finally have Debian working on this box. I think what threw me is the instructions kept trying to prompt me to look for the stripped-down netinstall image, when no such image existed for sparc. It did take a long time to download the entire disk (projected time was 4 hours for the first mirror I tried, on a high speed connection; I found another mirror and got it in 1:30). But at least it worked. And now that I have woody installed, I'm upgrading to testing. Thanks, jdb
Re: Debian Sparc Buildd
Jurij Smakov schrieb: On Tue, 15 Mar 2005, Blars Blarson wrote: As far as I understand, the main problems with sparc are not availability of hardware. [skip] There have been kernel porting issues, and I beleive additional help could be used there. Debian-installer could use more testing, especially on newer systems. USB keyboards and other hardware not in 5-year old workstations are areas that most need testing. sun4c/sun4d are not being supported in sarge, (at least for new installs) and it looks like sun4m (the last sparc32) will not be in etch even if sparc is a release architecture. While I would not mind having a faster machine available for building testing/debugging kernels, I agree with Blars that the lack of hardware may hardly be considered a bottleneck. Comments about other points: * Kernel situation seems to be more or less ok at the moment. Sparc kernel images are built from the common kernel-source, and all the patches we produce get promptly accepted upstream in most cases (thanks to Dave Miller and William Lee Irwin III for doing a good job!). It would be nice if people would be more active in testing new kernel - see the wiki page at [0] on how to help. I just secured myself a Blade 100. Should get it some time around next week. Has anybody on top of his head a source for RAM Modules (cheep and acessable from Germany) for that Baby? [-snip-] greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/
WG: Re: Bits (Nybbles?) from the Vancouver release team meeting
> In line with the subject of porting / obsolescence, I should mention > that some not terribly old UltraSPARC systems (my Ultra 10 for > example)are not even supported by Sun in Solaris 10. > > If we quit supporting these, I think they will just quit working. > At least that statement is not true. According to the release notes (http://docs.sun.com/app/docs/doc/817-0552/6mgbi4fh8?a=view) and my personal experience, Solaris 10 runs on anything sun4u with CPU speed > 200 MHz. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
