Re: X server and xinit works excellent....almost.
Chuck Swiger cswi...@mac.com wrote: My assumption still is: Not _every_ keyboard manufacturer does code the layout into the USB identification. If you tell me I'm wrong with this assumption, I'll be happy. :-) Folks are supposed to use a different product ID for different devices, so you can uniquely identify them. I can't promise that every vendor handles this perfectly, any more than folks always ensured that PCI ids uniquely identified a specific hardware version, but one should blame the vendor for being brain-damaged in such cases; it isn't a fault of the USB standard If someone manufactures a single type of keyboard -- using only one type of ASIC, one PCB/keyswitch layout, one kind of housing, etc. -- I'd say it is very much open to interpretation whether snapping on a different collection of keycaps makes it into a different product. Even if the manufacturer tried to cover for the possibility, e.g. by providing a jumper on the PCB which is supposed to be set according to the installed set of keycaps, there will still be cases where an end user replaces or rearranges the keycaps to change the layout and doesn't change the jumper setting. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Chuck Swiger cswi...@mac.com, 2011-11-09 22:10 (+0100): How would HAL know that the keyboard had a Swedish layout? No such information is sent through USB or PS/2 when you attach a keyboard. True for PS/2, but not true for USB-- the USB Vendor Product ID can identify different keyboard types and let you infer the country. I'm sorry I was unclear. I meant the USB device doesn't say what physical keyboard layout it has in any standardized way. There is nothing in the USB protocol about it. The product ID code might tell you something if you have a large database and the USB product ID is indeed different between two physical layouts. It might not be. For instance, while ANSI keyboards and ISO keyboards are bound to have different USB product IDs because of actually physical differences in the number of keys, the only thing that differs between, say, a German keyboard and a Swedish keyboard of the same model is what is printed on the keycaps. A vendor might see these as the same USB product ID. -- http://hack.org/mc/ Plain text e-mails, please. HTML messages sent to me are silently deleted. OpenPGP welcome, 0xE4C92FA5. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Samuel Magnusson samuel.magnuss...@bredband.net, 2011-11-09 21:52 (+0100): Because with HAL and DBUS enabled this InputDevice section is bypassed unless I also specify Option AutoAddDevices false. Which I understand gives the same result as not enabling HAL and DBUS in the first place. If you don't enable HAL and DBUS, you're using an X server compiled with HAL and DBUS support and you haven't set AutoAddDevices to false you won't get any input devices at all: no working mouse, no working keyboard. At least, this was my experience after an upgrade long ago. Quite frustrating. I learned about the AutoAddDevices first and later rebuilt my X server without HAL or DBUS support. -- http://hack.org/mc/ Plain text e-mails, please. HTML messages sent to me are silently deleted. OpenPGP welcome, 0xE4C92FA5. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Samuel Magnusson samuel.magnuss...@bredband.net, 2011-11-10 00:49 (+0100): Michael Cardell Widerkrantz wrote 2011-11-09 21:02: What new style XML method? I'm referring to what Polytropon said about all the new stuff required by X. As I understood him he was talking about the XML-files to give directions to HAL Ah! HAL! Good riddance! Perhaps you can file a Problem Report (PR) with a suggested text? I suggest you add the text to the handbook since I assume the X.org project won't touch manual pages for the ancient X servers we use in FreeBSD. As I understand you, the man-pages from Xorg that are in FreeBSD are not allowed to be altered unless the Xorg project do it themselves, I'm sure they can be altered in FreeBSD. I just thought it might be better to add the text to the handbook. Or both. Anyway, I wasn't aware that the FreeBSD X server was ancient and different from any other. :) We're a few versions behind the X.org bleeding edge since modern servers require kernel changes. Modern X.org servers require Kernel-based Mode Setting (KMS) and Graphics Execution Manager (GEM) and udev support. While it's likely there could be some udev glue on top of devd I don't know if someone is working on it. Warner, perhaps? KMS and GEM, mainly for the intel drivers, are being worked on: http://wiki.freebsd.org/Intel_GPU Also a good beginners tutorial on the fonts would be good, because as I understand it there is also an old and a new way with the core fonts and the font server, some methods belonging to one and some to the other. That's true. You can start by reading my blog post about it: http://hack.org/mc/blog/xfonter.html It's in Swedish, I'm afraid, but both your name and the fact that you were talking about a Swedish keyboard earlier makes me think you can cope with that. But if I do produce something, where should I send the PR and text? See the send-pr(1) manual page. Failing that, use: http://www.freebsd.org/send-pr.html -- http://hack.org/mc/ Plain text e-mails, please. HTML messages sent to me are silently deleted. OpenPGP welcome, 0xE4C92FA5. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Polytropon free...@edvax.de, 2011-11-10 01:30 (+0100): Now as it (almost?) works on FreeBSD, it's already deprecated by new Linux concepts such as udev, upower and other usomethings. Maybe they become available as interfaces on FreeBSD too, but my fear is... as soon as they are usable, there's already something else obsoleting them right away. :-( By then I'm sure Linux distributions have moved on to the Wayland Display System. Times like these I wish I had the time to bring back MGR from the dead: http://hack.org/mc/mgr/ -- http://hack.org/mc/ Plain text e-mails, please. HTML messages sent to me are silently deleted. OpenPGP welcome, 0xE4C92FA5. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
2011-11-09 21:52, Samuel Magnusson skrev: When I first installed Xorg I began by following the handbook, which means that I unwittingly did this to my poor rc.conf: hald_enable=YES dbus_enable=YES That meant that I would HAVE to go into the XML-stuff (to get swedish keys) If all you want is a swdish keyboard layout then put this in your ~/.xinitrc setxkbmap se ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Nov 10, 2011, at 2:25 AM, Michael Cardell Widerkrantz wrote: True for PS/2, but not true for USB-- the USB Vendor Product ID can identify different keyboard types and let you infer the country. I'm sorry I was unclear. I meant the USB device doesn't say what physical keyboard layout it has in any standardized way. There is nothing in the USB protocol about it. That's fairly said-- you'd have to query a database of vendor+product ids and see whether you can determine that a particular keyboard is for a given country and/or language. If you don't find a match, there isn't a good way of identifying the region of the device just via USB protocol. The product ID code might tell you something if you have a large database and the USB product ID is indeed different between two physical layouts. It might not be. For instance, while ANSI keyboards and ISO keyboards are bound to have different USB product IDs because of actually physical differences in the number of keys, the only thing that differs between, say, a German keyboard and a Swedish keyboard of the same model is what is printed on the keycaps. A vendor might see these as the same USB product ID. Different keycaps means a different product SKU, at least. If they use the same USB product ID, then you're going to have to define a keymap file / xmodmap / etc to associate the scan codes with the right character that's printed on the keycaps. FreeBSD's users generally are more technically inclined and might be willing to deal with this, but even so, I suspect that most folks would appreciate the system trying to figure out that an AZERTY keyboard layout means French, that JIS means Japanese, that QWERTZ probably indicates German / Swiss / Hungarian, etc. To my mind, though, that's a fallback for when you have a KVM or a PS/2-to-USB converter or suchlike in the way that prevents the device from being correctly recognized. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Chuck Swiger cswi...@mac.com, 2011-11-10 20:12 (+0100): Different keycaps means a different product SKU, at least. If they use the same USB product ID Yes. I think this is a quite common scenario. FreeBSD's users generally are more technically inclined and might be willing to deal with this, but even so, I suspect that most folks would appreciate the system trying to figure out that an AZERTY keyboard layout means French, that JIS means Japanese, that QWERTZ probably indicates German / Swiss / Hungarian, etc. Certainly. To my mind, though, that's a fallback for when you have a KVM or a PS/2-to-USB converter or suchlike in the way that prevents the device from being correctly recognized. Or when you have, say, a keyboard that physically is an ANSI keyboard (one less physical key compared to ISO keyboards) but still want, say, a Swedish keymap or, indeed, your very own keymap, unlike any other. Like me when I'm using one of my Happy Hacking Keyboards. Topre switches FTW! -- http://hack.org/mc/ Plain text e-mails, please. HTML messages sent to me are silently deleted. OpenPGP welcome, 0xE4C92FA5. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Thu, Nov 10, 2011 at 11:12 AM, Chuck Swiger cswi...@mac.com wrote: FreeBSD's users generally are more technically inclined and might be willing to deal with this, but even so, I suspect that most folks would appreciate the system trying to figure out that an AZERTY keyboard layout means French, that JIS means Japanese, that QWERTZ probably indicates German / Swiss / Hungarian, etc. I thought I'd mention that OS X takes an interesting approach to this. When you plug in a keyboard it doesn't recognize, it does a little dance where it tells you to press certain keys (e.g., Press the key to the right of the left Shift key, with a little graphic to help you understand which key it means) and from the results it infers the layout. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Nov 10, 2011, at 3:57 PM, David Brodbeck wrote: On Thu, Nov 10, 2011 at 11:12 AM, Chuck Swiger cswi...@mac.com wrote: FreeBSD's users generally are more technically inclined and might be willing to deal with this, but even so, I suspect that most folks would appreciate the system trying to figure out that an AZERTY keyboard layout means French, that JIS means Japanese, that QWERTZ probably indicates German / Swiss / Hungarian, etc. I thought I'd mention that OS X takes an interesting approach to this. When you plug in a keyboard it doesn't recognize, it does a little dance where it tells you to press certain keys (e.g., Press the key to the right of the left Shift key, with a little graphic to help you understand which key it means) and from the results it infers the layout. Indeed, yes-- that's KeyboardTypeSection, part of Setup Assistant.app used to perform initial configuration of a new system. While I think it makes a good example, I don't want to evangelize stuff from $REALJOB too strongly. :-) Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Thanks guys, that was really helpful! I now also installed the nVidia driver and it works well. The reason I didn't use it in the first place was that I had read that the old Geforce 2-card wasn't supported by the nVidia rivers anymore. And that nouveau (as replacement for nv) should be used instead. (But that was on a Gentoo Linux page when I tried that OS shortly before FreeBSD and thought it was the same with the drivers. Apparently I was wrong... I made a minimal install of Xorg and only downloaded nouveau. ) The zoom works just fine now for all resolutions supported. So I guess my driver issue is solved. I got the zap to work also, but first only by using the setxkbmap command in .xinitrc. Which made me remember that I had the exact same problem with my swedish keyboardmappings the very first time I started X. I just couldn't get it to work and nearly gave up before I tried the setxkbmap method and put them into .xinitrc, which saved me. Although I had put the exact same rules and layout options in xorg.conf and double checked the format and spelling hundreds of times. The problem was still there now: when I commented it out in .xinitrc I got the US keyboard in xterm in spite of the xorg.conf settings. It seemed like the X server just ignored all my keyboard options in xorg.config. Which it also did! (As I also colud confirm from the logfile) The thing that really made it was the Option AutoAddDevice off, which I had failed to notice. I realize that it was too long since I looked into the handbook, because it is in clear text there. Sorry for that! But since this autodetection seems to be the standard for Xorg now and it is so important issue to get things working, maybe it should be put in a highlighted box with Important! written on it. The thing is that I was also using other documentation and guides, like the manpages or books of maybe a couple of years old. This issue is not mentioned and the InputDevices sections in xorg.conf is just supposed to work. A not outdated example of unclarity: the man page xorg.conf(5) freshly installed with my system says: Option AutoAddDevices boolean If this option is disabled, then no devices will be added from HAL events. Enabled by default. It doesn't warn that if it is NOT disabled the InputDevice sections won't work at all. And no devices will be added sounds like a bad thing, so you rather leave this option enabled... And then in the INPUTDEVICE SECTION: Recent X servers employ input hotplugging to add input devices, with the HAL backend being the default backend for X servers since 1.4. It is usually not necessary to provide InputDevice sections in the xorg.conf if hotplugging is enabled. I smile when I read such things, because usually not neceesary to provide is a funny way to express not able to provide. :) It should be clearly stated that theese are two conflicting options and that autoconfiguration overrides manual entries. I think it always should be the reverse, but thats no big deal as long as it is very clear how to enforce the manual choices on the system. Of course it is logical that you can't have both, but I can assure you as a newbie with all that you have to learn that this detail is easy to miss. And when autoconfiguration overrides then you are lost without knowing why , because everything seems correctly configured except it doesn't work. Now I'm curious: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? And should HAL have discovered my swedish keyboard automatically in the first place, so there was something going wrong there? Thanks again for the help! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Samuel Magnusson wrote 2011-11-09 12:06: Now I'm curious: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? And should HAL have discovered my swedish keyboard automatically in the first place, so there was something going wrong there? Well don't bother answering, because I understand it from reading the handbook. It is clear to me now, it was just to much new info for my brain to handle earlier.. :) Now my original questions 3-4 still remain unsolved. This works for me: X :0 -terminate Ctrl-Alt-F1 xterm -display :0 Ctrl-Alt-F9 exit xterm.. which brings me back to the first console. But this doesn't work: X :0 -terminate vt4 Ctrl-Alt-F1 (doesn't respond) Ctrl-Alt-Backspace (doesn't respond) ssh-login from my laptop works so I can start a xterm -display :0 from there. But even if I can focus the xterm-window with the mouse the keyboard doesn't respond so I can't write any commands. If I kill -9 the X server and the login process on vt4 the processes disappears from the list but I am still not taken back to vt0 and the system hangs except for my ssh-login that still works. I have to shutdown or reboot from there. Any clue why? Is my command X :0 vt4 wrong or not supposed to work? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Wed, 09 Nov 2011 12:06:37 +0100, Samuel Magnusson wrote: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? I hope not! :-) As far as I understood the _current_ mechanism, the precedence is 1st xorg.conf, 2nd XML stuff, 3rd autodetect. You have X without HAL and DBUS? Use xorg.conf because this has worked for many years to centralize X configuration. You have X with HAL and DBUS, but don't want to use it? Reflect this choice in xorg.conf and continue with previous settings. You have X with HAL and DBUS, but some things aren't detected properly? Dive into the fun of XML and enter your settings in the appropriate files, whichever they currently may be. :-) There _are_ things that cannot be autodetected, and HAL needs to be configured to notice a localization deviation from the standard, which is en_US. That's what you are going to use the XML stuff for. In case you're _not_ using HAL with X, you have to make the settings in xorg.conf, like this: Section InputDevice Identifier Keyboard0 Driver kbd Option XkbModel pc105 Option XkbLayoutde Option XkbOptions terminate:ctrl_alt_bksp EndSection Note that putting the Zap key into this file seems to be more comfortable than putting it into some obscure XML files scattered across the file system. And completely independent from all those options, you still can _always_ use [ -f ~/.xmodmaprc ] xmodmap ~/.xmodmaprc in your X initialization file (usually ~/.xinitrc). This does _not_ say anything about what might become current when HAL is fully out of support (as it is already considered deprecated in Linux). And should HAL have discovered my swedish keyboard automatically in the first place, so there was something going wrong there? Can you tell me _how_ anything in software is supposed to know what characters are printed on the key caps of the keyboard? I'm not sure keyboard vendors do code localization variants into their USB identification numbers... This makes me assume the following: It's not possible to determine the localized layout of a keyboard. Just imagine I pop the german keycaps from my IBM model M keyboard and put a set of swedish caps on, would the system notice that change? :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Wed, 09 Nov 2011 13:19:44 +0100, Samuel Magnusson wrote: This works for me: X :0 -terminate Ctrl-Alt-F1 xterm -display :0 Ctrl-Alt-F9 exit xterm.. which brings me back to the first console. But this doesn't work: X :0 -terminate vt4 Ctrl-Alt-F1 (doesn't respond) Ctrl-Alt-Backspace (doesn't respond) Do you have ``Option DontVTSwitch false'' in xorg.conf? Any clue why? Is my command X :0 vt4 wrong or not supposed to work? What is the correct notation for the terminal device to start it on? Maybe ttyv4 (as in /etc/ttys)? -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Samuel Magnusson samuel.magnuss...@bredband.net, 2011-11-09 12:06 (+0100): Which made me remember that I had the exact same problem with my swedish keyboardmappings the very first time I started X. I just couldn't get it to work and nearly gave up before I tried the setxkbmap method and put them into .xinitrc, which saved me. Although I had put the exact same rules and layout options in xorg.conf and double checked the format and spelling hundreds of times. The problem was still there now: when I commented it out in .xinitrc I got the US keyboard in xterm in spite of the xorg.conf settings. XKB is a bit of a mystery compared to good old xmodmap. A while ago I tried to understand it. The result is a small guide on how you can use XKB to define your own keyboard mapping and load it without having to be root. I used my own version of a Swedish keyboard on a Happy Hacking Keyboard as an example: http://hack.org/mc/writings/xkb.html The thing that really made it was the Option AutoAddDevice off, which I had failed to notice. Yes, this is really important, especially if you don't want that dreadful HAL on your system. Considering that the default is on and HAL isn't a dependency for the X server, many users were surprised when they didn't have any working mouse nor keyboard! I don't use HAL and it seems even the X.org project has moved away from HAL even if such modern X.org X servers are not yet in ports. It doesn't warn that if it is NOT disabled the InputDevice sections won't work at all. And no devices will be added sounds like a bad thing, so you rather leave this option enabled... Perhaps you can file a Problem Report (PR) with a suggested text? I suggest you add the text to the handbook since I assume the X.org project won't touch manual pages for the ancient X servers we use in FreeBSD. Now I'm curious: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? What new style XML method? AFAIK the more modern X.org X servers uses the Linux udev instead of HAL. Those servers are not yet available on FreeBSD but presumably it would be possible to use devd for the same purpose. And should HAL have discovered my swedish keyboard automatically in the first place, so there was something going wrong there? How would HAL know that the keyboard had a Swedish layout? No such information is sent through USB or PS/2 when you attach a keyboard. This is up to your own language settings, either with what you have entered in the form of setxkbmap or xkbcomp in your .xinitrc/.xsession or your settings in the desktop environment of your choice. -- http://hack.org/mc/ Plain text e-mails, please. HTML messages sent to me are silently deleted. OpenPGP welcome, 0xE4C92FA5. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Polytropon wrote 2011-11-09 19:15: On Wed, 09 Nov 2011 12:06:37 +0100, Samuel Magnusson wrote: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? I hope not! :-) As far as I understood the _current_ mechanism, the precedence is 1st xorg.conf, 2nd XML stuff, 3rd autodetect. You have X without HAL and DBUS? Use xorg.conf because this has worked for many years to centralize X configuration. You have X with HAL and DBUS, but don't want to use it? Reflect this choice in xorg.conf and continue with previous settings. You have X with HAL and DBUS, but some things aren't detected properly? Dive into the fun of XML and enter your settings in the appropriate files, whichever they currently may be. :-) There _are_ things that cannot be autodetected, and HAL needs to be configured to notice a localization deviation from the standard, which is en_US. That's what you are going to use the XML stuff for. I like that precedence list, because the old way seems much clearer and simpler to me. If autodetection only does half the detecting and then lays the burden of a new and more complicated manual configuration, then not much is gained. And why on earth could they not just have left what needed to be manually configured in the xorg.conf and make it override the HAL default mode? That would be the logical and easy way, in my inexperienced opinion. So as I understand it from my mistakes this precedence list is only true under certain circumstances, and I fell in a nice little devilish newbie-trap. :) When I first installed Xorg I began by following the handbook, which means that I unwittingly did this to my poor rc.conf: hald_enable=YES dbus_enable=YES That meant that I would HAVE to go into the XML-stuff (to get swedish keys) , because I could configure the InputDevice section until blue in my face (which I also did), and still nothing would happen witht the keyboard layout. Because with HAL and DBUS enabled this InputDevice section is bypassed unless I also specify Option AutoAddDevices false. Which I understand gives the same result as not enabling HAL and DBUS in the first place. Its just an unnecessary circle, first enabling, then disabling. I have to give cred to the FreeBSD handbook because it is actually quite correct and clear on this point (as no other text I found was) and tells what to do if wanting to do it the old way. But for some reason that I cannot recall now, I didn't understand it right away and strayed away from the handbook to among other things the X.org website and the man pages and other introductory books, which doesn't warn about this at all. It just assumes that xorg.conf sections works as usual. But it didn't to my hald-enabled system. I never returned to the handbook, because I stumbled on the working method with setxkbmap which did override the HAL default layout. I left it as a big question mark to maybe get back to it later. When I started this thread I had no idea that my problem with zap could be related to the same keyboard problem I had encountered earlier. ...so I'm learning. :) Can you tell me _how_ anything in software is supposed to know what characters are printed on the key caps of the keyboard? I'm not sure keyboard vendors do code localization variants into their USB identification numbers... No I can't. :) I realized the unprobability of this when hitting the send button. And your comment is also a good argument for keeping the simpler keyboard configuration in xorg.conf, isn't it? Couldn't autodetection of the keyboard work together with xorg.conf just like when giving the command X -configure and /root/xorg.config.new is created? For example that detected my monitor, my graphics card and my installed drivers, and it put those as entrys in the file so it is easy to edit and add options if necessary. HAL could just put pc105 into the normal InputDevice section and let me fill in the Layout... What is there more than pc105 to autodetect then that I would need HAL to make my life easier? I guess these are decisions to be made by X.org though, and not by me.. I just wonder. :) Anyway, can you stand one more just curious-question from me? When I used the vesa and nouveau drivers they were automatically kldloaded when the X server read the xorg.conf file. But the nVidia driver I have to kldload manually because otherwise the X server doesn't find it. Of course I will put it in loader.conf, but is it normal? Should it not be loaded authomatically as the others? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Hi-- On Nov 9, 2011, at 12:02 PM, Michael Cardell Widerkrantz wrote: And should HAL have discovered my swedish keyboard automatically in the first place, so there was something going wrong there? How would HAL know that the keyboard had a Swedish layout? No such information is sent through USB or PS/2 when you attach a keyboard. True for PS/2, but not true for USB-- the USB Vendor Product ID can identify different keyboard types and let you infer the country. For example, see: http://www.linux-usb.org/usb.ids At the moment, I happen to be using a: Apple Pro Keyboard: Product ID: 0x020b Vendor ID: 0x05ac (Apple Inc.) Version: 4.20 Speed: Up to 12 Mb/sec Manufacturer: Mitsumi Electric Location ID: 0x3d111300 / 6 Current Available (mA): 250 Current Required (mA): 50 ...and this database would correctly let the system know that I'm using US layout: 020b Pro Keyboard [Mitsumi, A1048/US layout] If you figure out that a Logitech Tangentbord K120 (or an Apple MC184S) is connected, then you've got a Swiss keyboard, and so forth. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Michael Cardell Widerkrantz wrote 2011-11-09 21:02: Samuel Magnussonsamuel.magnuss...@bredband.net, 2011-11-09 12:06 (+0100): Now I'm curious: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? What new style XML method? AFAIK the more modern X.org X servers uses the Linux udev instead of HAL. Those servers are not yet available on FreeBSD but presumably it would be possible to use devd for the same purpose. I'm referring to what Polytropon said about all the new stuff required by X. As I understood him he was talking about the XML-files to give directions to HAL, and he used quotes so I think he meant supposedly new, or just newer than the classic configuration file but already the old new, as he seem to agree with you that HAL is on it's way out and should be avoided if possible. /Perhaps you can file a Problem Report (PR) with a suggested text? I suggest you add the text to the handbook since /I /assume the X.org project won't touch manual pages for the ancient X servers we use in FreeBSD. / As I understand you, the man-pages from Xorg that are in FreeBSD are not allowed to be altered unless the Xorg project do it themselves, and they won't do it because they have other more current things to do than updating deprecated documents? If so, maybe if just asked they would allow some modifications be done to it? Anyway, I wasn't aware that the FreeBSD X server was ancient and different from any other. :) But I'm a rookie so far.. I was actually thinking when struggling with this that I should learn this X keyboard configuration thoroughly and try to write a beginners tutorial, fail-safe and step by step to help avoiding these traps as I would know whats difficult to understand for a beginner. But I will have to learn a bit more first in that case so I'm not just easy to understand but also correct. I'll study your guide, thanks for the link! Also a good beginners tutorial on the fonts would be good, because as I understand it there is also an old and a new way with the core fonts and the font server, some methods belonging to one and some to the other. And migrating from Windows and Mac might be discouraging if there isn't a working desktop with visible text at least within an hour or two after installation. :) But if I do produce something, where should I send the PR and text? Cheers /Samuel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Thu, 10 Nov 2011 00:49:19 +0100, Samuel Magnusson wrote: Michael Cardell Widerkrantz wrote 2011-11-09 21:02: Samuel Magnussonsamuel.magnuss...@bredband.net, 2011-11-09 12:06 (+0100): Now I'm curious: Is it then so that in the new style Xorg the XML-method will override HAL, and this is the new default way of providing opitons that formerly were in the InputDevice sections in xorg.conf? What new style XML method? AFAIK the more modern X.org X servers uses the Linux udev instead of HAL. Those servers are not yet available on FreeBSD but presumably it would be possible to use devd for the same purpose. I'm referring to what Polytropon said about all the new stuff required by X. As I understood him he was talking about the XML-files to give directions to HAL, and he used quotes so I think he meant supposedly new, or just newer than the classic configuration file but already the old new, as he seem to agree with you that HAL is on it's way out and should be avoided if possible. Depends. If you are using a normal US keyboard and don't have any deviant needs, HAL autodetection of devices should work fine. And as it is X's default configuration, you could even omit xorg.conf if X detects your GPU and display properly. The problems start when you do something not-normal. In such cases, it seems that you better leave HAL and DBUS out of your system, if you don't see any use for them. In that case, the old-fashioned configuration methods should do what you want: centralized settings for X in xorg.conf. Setup once, then use. Anyway, I wasn't aware that the FreeBSD X server was ancient and different from any other. :) There is some delay in porting X's new features from Linux to FreeBSD. Linux is the platform that mostly drives that development. Some parts used by X and by desktop environments are specific to Linux. HAL was initally meant to be a kind of plugin system to get independent from the OS, but it didn't get that far. Now as it (almost?) works on FreeBSD, it's already deprecated by new Linux concepts such as udev, upower and other usomethings. Maybe they become available as interfaces on FreeBSD too, but my fear is... as soon as they are usable, there's already something else obsoleting them right away. :-( Those Linux developments often serve functionalities that have been present in FreeBSD for many years. One of the often cited things is automounting. FreeBSD's automounter amd, in combination with devd, can already automount things independently from desktop environments. It could do that already 5 years ago. This setup can also handle webcams and USB mass storage. The question is: How to interface that with a desktop environment? Those IDE's development is also mainly driven on Linux. An example is Xfce which lost some functionality on FreeBSD because those parts have been rewritten with Linux-only back-ends in mind. Maybe other things will follow, maybe Gnome 3? Who knows... And migrating from Windows and Mac might be discouraging if there isn't a working desktop with visible text at least within an hour or two after installation. :) No problem in that, see FreeSBIE - all what you said, plus you don't need to install anything. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Wed, 09 Nov 2011 13:10:20 -0800, Chuck Swiger wrote: Hi-- On Nov 9, 2011, at 12:02 PM, Michael Cardell Widerkrantz wrote: And should HAL have discovered my swedish keyboard automatically in the first place, so there was something going wrong there? How would HAL know that the keyboard had a Swedish layout? No such information is sent through USB or PS/2 when you attach a keyboard. True for PS/2, but not true for USB-- the USB Vendor Product ID can identify different keyboard types and let you infer the country. Can - I think it's not standard to do so. For example, see: http://www.linux-usb.org/usb.ids Just checked, and the exception is right here: I'm using a Sun USB keyboard + mouse, 0x0430 = Sun Microsystems, Inc. is correct, but 0x100e = 24.1 LCD Monitor v4 / FID-638 Mouse seems to be nonsense. It's a mouse, _infront_ of a 24 monitor, but that's an EIZO CRT. :-) In this regards, it's also strange how FreeBSD could forget USB information it once had. On my old 5.x system, I got dmesg lines like that: ukbd0: Sun Microsystems Type 6 USB keyboard, rev 1.00/1.02, addr 3, iclass 3/1 ums0: Sun Microsystems Type 6 USB mouse, rev 1.00/1.02, addr 2, iclass 3/1 But since 7.0 (6.0 hasn't been introduced to my home system), I get ukbd0: vendor 0x0430 product 0x0005, class 0/0, rev 1.00/1.02, addr 3 on uhub1 ums0: vendor 0x0430 product 0x0100, class 0/0, rev 1.00/1.02, addr 2 on uhub1 Note that the corresponding file in the source tree containing the USB devices still has the proper data! And I haven't changed things on hardware side. But maybe this is because the USB subsystem has had many changes... Now that I have a type 7 keyboard, the USB information still is not useful: % usbconfig -u 1 -a 3 dump_info ugen1.3: Sun USB Keyboard vendor 0x0430 at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON % usbconfig -u 1 -a 2 dump_info ugen1.2: product 0x100e vendor 0x0430 at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE % dmesg | grep ^u[km] ukbd1: vendor 0x0430 Sun USB Keyboard, class 0/0, rev 2.00/1.05, addr 3 on usbus1 ums0: vendor 0x0430 product 0x0100, class 0/0, rev 1.00/1.02, addr 4 on usbus1 ums0: 3 buttons and [XY] coordinates ID=0 You can also see that dmesg logs different data (0x100e vs. 0x0100). At the moment, I happen to be using a: Apple Pro Keyboard: Product ID: 0x020b Vendor ID: 0x05ac (Apple Inc.) Version: 4.20 Speed: Up to 12 Mb/sec Manufacturer: Mitsumi Electric Location ID: 0x3d111300 / 6 Current Available (mA): 250 Current Required (mA): 50 ...and this database would correctly let the system know that I'm using US layout: 020b Pro Keyboard [Mitsumi, A1048/US layout] If you figure out that a Logitech Tangentbord K120 (or an Apple MC184S) is connected, then you've got a Swiss keyboard, and so forth. This is fine as long as you're going to keep that language settings. However, there are users who need a non-US language on a US keyboard layout - or vice versa. In such a case, the autodetection doesn't help. Your example with Apple hardware corresponds to my experience. I also have an older Mac keyboard which works fine on FreeBSD, including proper device identification. My assumption still is: Not _every_ keyboard manufacturer does code the layout into the USB identification. If you tell me I'm wrong with this assumption, I'll be happy. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Polytropon wrote 2011-11-09 19:19: On Wed, 09 Nov 2011 13:19:44 +0100, Samuel Magnusson wrote: This works for me: X :0 -terminate Ctrl-Alt-F1 xterm -display :0 Ctrl-Alt-F9 exit xterm.. which brings me back to the first console. But this doesn't work: X :0 -terminate vt4 Ctrl-Alt-F1 (doesn't respond) Ctrl-Alt-Backspace (doesn't respond) Do you have ``Option DontVTSwitch false'' in xorg.conf? No I haven't, so I tried it now for completeness sake. But there was no difference. It shouldn't be needed, and VTSwitching works just fine as long as I don't try to choose a virtual terminal to start it in. I tried putting the option there and it is no difference, the computer hangs on the display, and when viewing sockstat -4 from the remote login I could see an awful lot of dbus and hal activity. Since those 'fellas' were the cause of so many of my woes I disenabled them :) , rebooted and tried again. At first no difference except that when I killed the server I was no longer stuck with the black screen and visually returned to tty0. I was not given back the console though and the login was still hanged. Any clue why? Is my command X :0 vt4 wrong or not supposed to work? What is the correct notation for the terminal device to start it on? Maybe ttyv4 (as in /etc/ttys)? Nope. Even if I no longer trust the Xorg man page to 100%, it clearly states vtXX as the notation to use for the option. And when viewing the log it clearly says that it start up the server in vt4 and it doesn't protest but goes on a good while before it stops. Interesting is that it stops without any error message. It is right after reading the keyboardsettings from xorg.conf, the first informational line after that: (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) Then the file ends. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
Polytropon skrev 2011-11-10 01:30: On Thu, 10 Nov 2011 00:49:19 +0100, Samuel Magnusson wrote: And migrating from Windows and Mac might be discouraging if there isn't a working desktop with visible text at least within an hour or two after installation. :) No problem in that, see FreeSBIE - all what you said, plus you don't need to install anything. :-) Haha, ok, then its just me that wanted to NOT install a readybuildt desktop, just for learning more about the architechture by trying to install everything manually. I'll have to suffer the consequences of my own decisions... without complaining, which I am not by the way. Thanks for the overview! (And never mind the autoloading question, i found it out in the logfile. Nothing important just a wrong searchpath it seemed. I also succeeded with the vtXX option several times. It was after disabling hal and dbus, but I'm not sure it's because of that, as now it does not function again. It seems unstable at least. But I don't know if I care that much anyway.. ) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Nov 9, 2011, at 5:01 PM, Polytropon wrote: In this regards, it's also strange how FreeBSD could forget USB information it once had. On my old 5.x system, I got dmesg lines like that: ukbd0: Sun Microsystems Type 6 USB keyboard, rev 1.00/1.02, addr 3, iclass 3/1 ums0: Sun Microsystems Type 6 USB mouse, rev 1.00/1.02, addr 2, iclass 3/1 A USB standard device descriptor includes iManufacturer and iProduct fields, which are likely the source of the strings displayed above. I guess the new USB stack doesn't bother to display them. Now that I have a type 7 keyboard, the USB information still is not useful: % usbconfig -u 1 -a 3 dump_info ugen1.3: Sun USB Keyboard vendor 0x0430 at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON % usbconfig -u 1 -a 2 dump_info ugen1.2: product 0x100e vendor 0x0430 at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE % dmesg | grep ^u[km] ukbd1: vendor 0x0430 Sun USB Keyboard, class 0/0, rev 2.00/1.05, addr 3 on usbus1 ums0: vendor 0x0430 product 0x0100, class 0/0, rev 1.00/1.02, addr 4 on usbus1 ums0: 3 buttons and [XY] coordinates ID=0 You can also see that dmesg logs different data (0x100e vs. 0x0100). The 0x0100 is for the mouse; the 0x100e is probably a USB hub, perhaps within the keyboard if the mouse attaches to the keyboard, although the database suggests it was a USB hub within a monitor. If you figure out that a Logitech Tangentbord K120 (or an Apple MC184S) is connected, then you've got a Swiss keyboard, and so forth. This is fine as long as you're going to keep that language settings. However, there are users who need a non-US language on a US keyboard layout - or vice versa. In such a case, the autodetection doesn't help. The idea is that autodetection provides a suggested default, at least if it can identify a country for the input devices which are connected to the system. But users should be able to set up their own language preferences, which might be different from the system default and from other user's settings. Your example with Apple hardware corresponds to my experience. I also have an older Mac keyboard which works fine on FreeBSD, including proper device identification. My assumption still is: Not _every_ keyboard manufacturer does code the layout into the USB identification. If you tell me I'm wrong with this assumption, I'll be happy. :-) Folks are supposed to use a different product ID for different devices, so you can uniquely identify them. I can't promise that every vendor handles this perfectly, any more than folks always ensured that PCI ids uniquely identified a specific hardware version, but one should blame the vendor for being brain-damaged in such cases; it isn't a fault of the USB standard Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Samuel Magnusson wrote: 1. I can?t zap the server with Ctrl-Alt-Backspace. Nothing at all happens. I have checked that it isn't disabled in xorg.conf, and even tried to put in the reverse boolean value there. Not that I couldn't live without zapping, but...when I know about it that it should be there and it is taken fom me I feel an URGE to get the zap! Zapping is still allowed by default, but a key combination is not assigned. That can be done in .xinitrc or .xsession: setxkbmap -option terminate:ctrl_alt_bksp It can also be done in xorg.conf: Section InputDevice Identifier Keyboard0 Driver kbd Option XkbOptions terminate:ctrl_alt_bksp EndSection 2. Not surprisingly I was also unable to use the Ctrl-Alt-Keypad+/- for zooming between the different resolution modes. But then I remembered that I had changed configuration from vesa driver to nouveau (with some patch that I downloaded according to instructions in ports). When I switched back to vesa it worked! Still no zapping though, and no higher resolution than 1024x768. vesa is very limited, only supporting standard modes up to 1024x768 or 1280x1024. Some vendors add other modes, but they aren't common. nouveau is an open driver for the very closed Nvidia hardware. The closed Nvidia drivers (x11/nvidia-driver*) are supposed to work quite well. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011 08:14:48 -0700 (MST), Warren Block wrote: On Tue, 8 Nov 2011, Samuel Magnusson wrote: 1. I can?t zap the server with Ctrl-Alt-Backspace. Nothing at all happens. I have checked that it isn't disabled in xorg.conf, and even tried to put in the reverse boolean value there. Not that I couldn't live without zapping, but...when I know about it that it should be there and it is taken fom me I feel an URGE to get the zap! Zapping is still allowed by default, but a key combination is not assigned. That can be done in .xinitrc or .xsession: setxkbmap -option terminate:ctrl_alt_bksp It can also be done in xorg.conf: Section InputDevice Identifier Keyboard0 Driver kbd Option XkbOptions terminate:ctrl_alt_bksp EndSection There is a 3rd option, especially useful when X is run with DBUS and HAL (the default configuration, as well as the package configuration), and it involves fun with XML. :-) File /usr/local/etc/hal/fdi/policy/x11-input.fdi ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.x11_options.XkbOptions type=stringterminate:ctrl_alt_bksp/merge /match /device /deviceinfo And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option DontZap off'' in the ServerFlags section. So, as you're already dealing with xorg.conf, use Warren's suggestion, as it works independently of all the new things required by X, and also conforms to the concept of concentrating X's configuration in one configuration file (rather than scattering settings across the file system). vesa is very limited, only supporting standard modes up to 1024x768 or 1280x1024. Some vendors add other modes, but they aren't common. nouveau is an open driver for the very closed Nvidia hardware. The closed Nvidia drivers (x11/nvidia-driver*) are supposed to work quite well. I'm using nvidia-driver here which works better than nouveau and nv (the one that comes with X.org); I haven't tested VESA as in most cases, it's _not_ what one wants. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option DontZap off'' in the ServerFlags section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Warren Block wrote: On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option DontZap off'' in the ServerFlags section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. Nope, just tested and I'm wrong. DontZap Off is needed with X.Org X Server 1.7.7. Sorry about that. I recommend adding the option to ServerLayout and doing away with the extra complication of a ServerFlags section. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011 13:33:55 -0700 (MST), Warren Block wrote: On Tue, 8 Nov 2011, Warren Block wrote: On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option DontZap off'' in the ServerFlags section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. Nope, just tested and I'm wrong. DontZap Off is needed with X.Org X Server 1.7.7. Sorry about that. I recommend adding the option to ServerLayout and doing away with the extra complication of a ServerFlags section. Good suggestion, the Handbook should be changed according to that if it really works (and is, in my opinion, easier). My statement regarding the xorg.conf _and_ XML fun wasn't a personal experience and testing (xorg-server-1.7.7_2,1 here), but the Handbook said so: http://www.freebsd.org/doc/handbook/x-config.html It's mentioned directly beneath the XML fun in 6.4.2. There's also a ServerLayout _or_ ServerFlags statement for the ``Option AutoAddDevices false'' setting, right before the XML fun for setting a localized keyboard begins... :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Polytropon wrote: On Tue, 8 Nov 2011 13:33:55 -0700 (MST), Warren Block wrote: On Tue, 8 Nov 2011, Warren Block wrote: On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option DontZap off'' in the ServerFlags section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. Nope, just tested and I'm wrong. DontZap Off is needed with X.Org X Server 1.7.7. Sorry about that. I recommend adding the option to ServerLayout and doing away with the extra complication of a ServerFlags section. Good suggestion, the Handbook should be changed according to that if it really works (and is, in my opinion, easier). It's already in there, right before Option DontZap Off. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
