Re: hard lockups with RC1
On 3 November 2011 07:37, Ashley Williams wrote: >> I've seen a few of these, too, in RC-1. I assumed they might be related >> to my having recently upgraded to the flash 11 port, but hadn't gotten >> around to reporting anything yet. Like you, I have no hard data to >> base any conclusions on as to what's causing the lockups. > > I can confirm Flash does cause the lock up, but I'm running flash 10, not 11. > Nevertheless this is a problem with linux emulation, not flash > Turns out this was caused by an out of date nvidia driver. Updated to nvidia-driver-285.05.09 and that solved the problem. ___ 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"
BUS_SETUP_INTR definition
Hello, I learning interrupt handling inside FreeBSD kernel but can't find BUS_SETUP_INTR() function realization or even definition. Could somebody advice me where defined and realized BUS_SETUP_INTR() function/macro? -- With best wishes Sergey Ryazanov ___ 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"
changing baud rate without recompiling
hi i wanna have serial console communication with the other system. i want to have baud rate 115200 for this communication but the default is 9600. i test the following options but the baud rate is 9600 yet: - add the following commands to the /boot/loader.conf file: boot_multicons=”YES” boot_serial=”YES” comconsole_speed=”115200” console=”comconsole,vidcobsole” - change the baud rate in /etc/ttys file - stty -f /dev/ttyu0 115200 - change the baud rate in /etc/rc.d/serial file when i use "stty -f /dev/ttyu0.init 115200" the baud rate for ttyu0.init change to 115200. after that i use "kill -1 1" in order to reinitialize devices but nothing happened and the baud rate for ttyu0 is still 9600. i know adding the "COM_CONSOLE_SPEED=115200" to make.conf and recompile it, change the baud rate but i want to know if there is a way to change it without recompiling. please let me know if there is any way to do that. my FreeBSD is 8.0 thanks. ___ 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"
sed vs gnu sed
'Hi all, I'm trying to move a script from a linux box to a freebsd box. All going well as its just a bash script and bash is bash, however there is one line I'm unable to use directly, as bsd sed (correctly according to SUS at least, I believe[1]) appends a newline when writing to standard out, gnu sed doesnt. example BSD [backup@banshee ~]$ echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | sed -n 's/[[:space:]]*;[[:space:]]*/;/gp' /boot:7:1:5;/:7:1:5;/var:7:1:5 [backup@banshee ~]$ LINUX [backup@amber ~]$ echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | sed 's/[[:space:]]*;[[:space:]]*/;/g' /boot:7:1:5;/:7:1:5;/var:7:1:5[backup@amber ~]$ is there any easy way to make our sed do the same as gnu sed here? for now I have encapsulated the whole thing in a subshell [backup@banshee ~]$ echo -n $(echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | sed -n 's/[[:space:]]*;[[:space:]]*/;/gp') /boot:7:1:5;/:7:1:5;/var:7:1:5[backup@banshee ~]$ Which works but seems a little hackish. Vince [1]http://pubs.opengroup.org/onlinepubs/007908799/xcu/sed.html ' Whenever the pattern space is written to standard output or a named file, /sed/ will immediately follow it with a newline character. " ___ 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: changing baud rate without recompiling
On Wed, Nov 9, 2011 at 10:11 AM, saeedeh motlagh wrote: > - change the baud rate in /etc/ttys file (...) > when i use "stty -f /dev/ttyu0.init 115200" the baud rate for > ttyu0.init change to 115200. after that i use "kill -1 1" in order to > reinitialize devices but nothing happened and the baud rate for ttyu0 > is still 9600. Are you sure you really updated /etc/ttys correctly? ttyu0 "/usr/libexec/getty std.115200" dialup on secure What does 'ps ax | grep getty' say? Something like this: 1416 u0 Is+0:00.24 /usr/libexec/getty std.9600 ttyu0 or like this: 1416 u0 Is+0:00.24 /usr/libexec/getty std.115200 ttyu0 Then, check that std.115200 is indeed in /etc/gettytab. Save for getty, I don't know what would reset the speed to 9600... Maybe some weird setting in /etc/login.conf? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: sed vs gnu sed
On 09/11/2011 10:30, Vincent Hoffman wrote:
is there any easy way to make our sed do the same as gnu sed here?
for now I have encapsulated the whole thing in a subshell
[backup@banshee ~]$ echo -n $(echo -n "/boot:7:1:5; /:7:1:5;
/var:7:1:5" | sed -n 's/[[:space:]]*;[[:space:]]*/;/gp')
/boot:7:1:5;/:7:1:5;/var:7:1:5[backup@banshee ~]$
Which works but seems a little hackish.
You can do it with awk(1):
# echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | \
awk ' { gsub("[[:space:]]*;[[:space:]]*", ";", $0) ; printf "%s", $0 }'
Not sure if that's any better than your solution using echo though.
Also trivial in perl(1) or python(1) or whatever, but it seems a waste
to fire up a whole perl interpreter just to do that.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
___
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: operapluginwraper
On Tuesday 08 November 2011 18:43:05 Polytropon wrote: > On Tue, 8 Nov 2011 15:33:01 -0600, ajtiM wrote: > > I don't have /proc on my system and I don't know why I should have it? > > You'll need it in case you're using Linux ABI stuff, and > if I remember correctly, this is required for the Opera > "Flash" plugin. > > I'm using such a combination here. That's why I have > > # Device Mountpoint FStype Options Dump Pass > # - -- --- --- - > linproc /compat/linux/proc linprocfsrw 00 > > in /etc/fstab. This requires > > options COMPAT_LINUX > options LINPROCFS > options LINSYSFS > > in your kernel config, or load the corresponding kernel > modules. The line > > linux_enable="YES" > > in /etc/rc.conf should do that. Thank you. But as I nderstand the Opera should be FreeBSD native. I didn't installed Linux version. And I don't have flash plugin installed either. BTW I use gnash. Mitja http://jpgmag.com/people/lumiwa ___ 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: BUS_SETUP_INTR definition
2011/11/9 Sergey Ryazanov : > I learning interrupt handling inside FreeBSD kernel but can't find > BUS_SETUP_INTR() function realization or even definition. > Could somebody advice me where defined and realized BUS_SETUP_INTR() > function/macro? I found the answer on one's own. BUS_SETUP_INTR() is the inline function defined in /usr/obj/usr/src/sys/XXX/*/bus_if.h which is generated during build time from /sys/kern/bus_if.m template. -- With best wishes Sergey Ryazanov ___ 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"
Disc encryption during installation
Hi, I was wondering whether there is any work being done in order to provide support for (full) disk encryption during installation. I know this can be done by installing a minimal system, manually setup encryption and install. But it would be nice to have something working out-of-the-box... P.S.: please keep me on CC, I'm not on the list. Cheers, -- Luis Henriques ___ 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"
Custom compiler/{C,CXX,F}FLAGS and /etc/make.conf - how to?
Dear ALL, The subject says it all. I'm trying to push out of my box every ounce of performance, perhaps even with (yet experimental) path64 compiler. So my question is as simple as that: what is the precise spell to put in make.comf to get (while not disrupting the ports infrastructure!) -march=amdfam10 if compiler is lang/gcc46 and -march=barcelona for path64 (perhaps yet another flags as well if toolchain supports them)? TIA, Vladimir ___ 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"
portupgrade -P does not 'su'?
Hello. I'd like to install a port with 'portinstall -P' from a non-root user and it requires an obvious dependency I already have built to be reused. But portinstall doesn't seem to brace it into the 'su root -c': $ portinstall -vpP devel/p5-Test-Class [..] ---> Installing 'p5-Module-Build-0.3800_1' from a package ---> Installation of p5-Module-Build-0.3800_1 started at: Mon, 07 Nov 2011 15:57:56 +0400 ---> Installing the new version via the package lib/perl5/5.14.1/man/man3/inc::latest.3.gz: Can't create 'lib/perl5/5.14.1/man/man3/inc::latest.3.gz': Permission denied [..] ** Command failed [exit code 2]: /usr/bin/script -qa /tmp/portinstall2007-84470-1midf4x-0 /usr/bin/env UPGRADE_TOOL=portupgrade UPGRADE_PORT=p5-Module-Build-0.3800_1 UPGRADE_PORT_VER=0.3800_1 /usr/sbin/pkg_add -f /usr/ports/packages/All/p5-Module-Build-0.3800_1.tbz It does use to be all ok with 'pkg_delete ... make install' sequence though. Any clues? ps. Same goes here about copying the obsoleted shared libraries to /usr/local/lib/compat/pkg -- Peter Vereshagin (http://vereshagin.org) pgp: A0E26627 ___ 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: "Unprintable" 8-bit characters
On Tue, 8 Nov 2011 20:59:48 -0600, Conrad J. Sabatier wrote:
> Same here. I've been "guilty" as well of neglecting to properly adjust
> my console configuration.
Sometimes "just works" in combination with lazyness beats
all proper concepts of doing things. :-)
> Doesn't using "LC_ALL" obviate the need to set any of the other LC_*
> variables? At least, that's always been my understanding of it.
I have to admit that I haven't fully understood everything
in that relation, but it seems that the $LC_* (!ALL) can
modify "subsets" of what $LC_ALL defines. Languages and
character sets can be assigned independently (e. g. english
program messages, but german file names properly displayed).
> But, getting back to something you said earlier, what did you mean
> exactly about the precedence of LANG vs. LC_*?
There is, if I remember correctly, the idea that _if_
$LANG is set, $LC_* won't be considered at all, even
if they are set.
http://www.freebsd.org/doc/handbook/using-localization.html
See 24.3.4.1.1.1 and 24.3.4.1.2.
> Yes, and this is one area where the labels are more than a little
> misleading as well. My natural inclination is think of UTF-8 as being a
> single-byte representation for each character in the set, whereas
> UTF-16, as the name implies, would be the "wide", 2-byte version.
> Nonetheless, as I posted earlier in this thread, according to the info
> in gucharmap, the representations of the umlauted "u" are just the
> opposite of this:
>
> UTF-8: 0xC3 0xBC
> UTF-16: 0x00FC
>
> Go figure, huh? :-)
I think Robert did explain it very good: While UTF-16 is
a "fixed width" (2 byte) representation, UTF-8 is "variable
width" (1 byte _or_ two byte).
> > But returning to the original question, I think Robert
> > did explain it very well: There is no real consensus
> > about what the different codings should mean. They
> > were meant to unify the representation of a very large
> > set of characters, but basically there are many inter-
> > pretations now, and how they show up to the user depends
> > on the font in use, _if_ it has this mapping or that,
> > or none.
>
> This seems rather unfortunate to me. You would think that, by now,
> some "standard" character set might have emerged that would allow one
> to use, at the very least, the "Western" characters (as opposed to
> the "Eastern" or "Oriental" or "Asian", if you will) with a reasonable
> expectation that others will see what was intended.
Assumptions, wishes, conclusions and hopes do differ from
reality. :-)
For example, in October I had to assist working on a
document containing german text and chinese symbols.
Decision: We use UTF-8 so the chinese symbols can appear
in the input. A name: Weng Tonghe [][][]. The brackets
should symbolize the three characters for that name.
They did show up properly in the editor, but on the
printed page... Weng Tonghe [][]. What? Two? But there
were three on input! As we found out, the "he" used
in input was the wrong one (there are several "he"s),
and the font used to render the text did not have that
particular "he". When we found the correct one, finally
three characters appeared, as intended and correct.
This should show: You _never_ know where things are
wrong when something is missing - settings, fonts,
who knows. In relation to file names, this is not a
problem of the file system as it will store any name
you want, but if you can actually SEE or USE that
file name - that's a completely different thing.
> > Again a fine demonstration why file names should be
> > limited to printable ASCII and no spaces if you want
> > them to work everywhere. :-)
>
> Well, for myself, personally, I'm a bit of a stickler for "language
> authenticity", you might call it. Having studied both German and
> French rather extensively in my younger days, I'm quite fond of both
> languages, and rather keen on seeing them represented accurately (I
> especially wince at the use of the plain, unaccented vowel followed by
> an "e" in place of the umlaut, and to a lesser degree, the use of "ss"
> in place of Esszett), which has caused me no small amount of confusion,
> aggravation and frustration over the years, to be sure! :-)
Make sure to call it "Eszett" ("Es" = S and "Zett" = Z).
The teletyping conventions suggests to dissolve "ß" to "sz",
because it's easier to recombine "sz" to "ß" because it's
likely to be correct, whereas recombining "ss" to "ß" is
often wrong, as there are too many correct "ss" in texts.
Example:
Mißwirtschaft -> Miszwirtschaft -> Mißwirtschaft ===> good.
Messer -> Meßer ===> wrong.
In names (e. g. of towns): Staßfurt (right) != Stassfurt (wrong).
Note that !("sz" <-> "ß") in all cases, and !("ss" <-> "ß")
as well, as the rule states that only a non-truncatable "ss"
is to be set as Eszett. There are only few "sz" that are
"real 'sz'", typically in word gaps, e. g. Reiszange. :-)
The "funny" things start when diacritic marks and other
non-US-ASCII representable elements change
Re: operapluginwraper
On Wed, 9 Nov 2011 05:28:43 -0600, ajtiM wrote: > But as I nderstand the Opera should be FreeBSD native. I didn't installed > Linux version. And I don't have flash plugin installed either. BTW I use > gnash. I'm also using the native BSD version of Opera, but with the following set of packages and wrappers: opera-11.50 opera-linuxplugins-11.50 nspluginwrapper-1.4.4 linux-f10-flashplugin-10.3r183.5 This was mainly because of following the handbook. So I think the dependency to the Linux /proc comes from the "Flash" plugin (Linux). -- 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: "Unprintable" 8-bit characters
It's worth noting, too, that most of the non-Unicode encoding systems predate the Internet. When computers weren't really talking to each other, there was no real emphasis on interoperability, and every OS tended to come up with their own way of encoding foreign languages. Languages like French, German, and English generally have it easy -- almost everything ended up being Latin1 (aka ISO 8859-1). For other languages it can be much more complicated. There are at least three commonly used encoding systems for Chinese. Unicode is gradually winning, but you'll still find, for example, a lot of Chinese documents in GB2312 and Big5. ___ 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: Disc encryption during installation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/9/11 11:06 AM, Luis Henriques wrote: > Hi, > > I was wondering whether there is any work being done in order to provide > support for (full) disk encryption during installation. I know this can > be done by installing a minimal system, manually setup encryption and > install. But it would be nice to have something working out-of-the-box... > > P.S.: please keep me on CC, I'm not on the list. > > Cheers, > -- > Luis Henriques Hi Luis, If you install FreeBSD with the PC-BSD installer, you can select the disk encryption option. See here for more information: http://wiki.pcbsd.org/index.php/Disk_Encryption Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk66wpgACgkQ0sRouByUApDB7gCgmbkDv7urHmYLqq2+6B3d1gvy ubAAoIm/hUU4quW64O482P9/xPTZ+303 =zkVY -END PGP SIGNATURE- ___ 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 "XkbLayout""de" 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: Disc encryption during installation
Hi Greg, On Wed, Nov 09, 2011 at 01:12:40PM -0500, Greg Larkin wrote: > Hi Luis, > > If you install FreeBSD with the PC-BSD installer, you can select the > disk encryption option. See here for more information: > http://wiki.pcbsd.org/index.php/Disk_Encryption Thanks a lot for your reply. I am not quite familiar with PC-BSD and I was not aware it had this built-in. Unfortunately, I am not actually targetting x86 platforms, which means that PC-BSD is not an option. Cheers, -- Luis Henriques ___ 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"
DBUS + kvm breaks X server (was: X server and xinit works excellent....almost.)
Since this has been mentioned, I though I'd take the opportunity ... Polytropon writes: > 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. :-) I have two systems - one Windows, one FreeBSD - that share monitor, keyboard, and mouse via a kvm. FreeBSD had both HAL and DBUS installed and activated in rc.conf. Scenario: I'm working on the FreeBSD system, and switch to the WIndows system (push the button on the kvm) everything's fine. But when I switch back, I an now sitting at the Xdm prompt; I'm guessing this means X has crashed. I experimented a little and discovered if I disable DBUS after initial boot, this no longer happens. (It makes some other things unhappy, but I can live with that.) Anyone have anyideas what might be happening and how to unbreak this? Robert Huff ___ 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: DBUS + kvm breaks X server (was: X server and xinit works excellent....almost.)
On Wed, 9 Nov 2011, Robert Huff wrote: I have two systems - one Windows, one FreeBSD - that share monitor, keyboard, and mouse via a kvm. FreeBSD had both HAL and DBUS installed and activated in rc.conf. Scenario: I'm working on the FreeBSD system, and switch to the WIndows system (push the button on the kvm) everything's fine. But when I switch back, I an now sitting at the Xdm prompt; I'm guessing this means X has crashed. I experimented a little and discovered if I disable DBUS after initial boot, this no longer happens. (It makes some other things unhappy, but I can live with that.) Anyone have anyideas what might be happening and how to unbreak this? Are the keyboard and mouse USB devices? A KVM should not disconnect them on switching, but maybe it does. Try it without HAL by adding Option "AutoAddDevices" "Off" to ServerLayout in xorg.conf. ___ 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 , 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: DBUS + kvm breaks X server (was: X server and xinit works excellent....almost.)
On Wed, 9 Nov 2011 14:02:07 -0500 Robert Huff articulated: > > Since this has been mentioned, I though I'd take the > opportunity ... > > Polytropon writes: > > > 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. :-) > > I have two systems - one Windows, one FreeBSD - that share > monitor, keyboard, and mouse via a kvm. FreeBSD had both HAL and > DBUS installed and activated in rc.conf. > Scenario: I'm working on the FreeBSD system, and switch to the > WIndows system (push the button on the kvm) everything's fine. > But when I switch back, I an now sitting at the Xdm prompt; > I'm guessing this means X has crashed. > I experimented a little and discovered if I disable DBUS after > initial boot, this no longer happens. (It makes some other things > unhappy, but I can live with that.) > Anyone have anyideas what might be happening and how to > unbreak this? I have virtually the same setup. A wireless keyboard/mouse that transmits to a USB device. The Windows systems activates virtually instantaneously; however, the FreeBSD system hangs for five seconds or more before it becomes responsive. Other than that, I have not noticed any problems (yet). Both HAL and DBUS are activated via the rc.conf file and I have not made any special modifications to the system config files. -- Jerry ✌ jerry+f...@seibercom.net Disclaimer: off-list followups get on-list replies or ignored. Do not CC this poster. Please do not ignore the "Reply-To" header. http://www.catb.org/~esr/faqs/smart-questions.html ___ 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"
Problems with ioctl
Hi!!.. I read your post on http://lists.freebsd.org/pipermail/freebsd-questions/2011-August/232945.html, and I have a similar problem. I my case I try to set and unset the RTS pin of the serial port, I use the ioctl() function with the TIOCMGET and TIOCMGET, the program works very well when I use the serial port (COM1) but when I use a USB<->COM (like you) converter the ioctl() function return me a fail, the error is "Invalid Argument". I need some solution or if you can recommend me any page or put me in contact with any other person. Any help will be very useful. My name is Juan Rodriguez and I'm from Paraguay. Thanks!!. P.S.: Sorry my English is not very good. ___ 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 Magnusson, 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: sed vs gnu sed
On 11/09/11 05:30, Vincent Hoffman wrote: 'Hi all, I'm trying to move a script from a linux box to a freebsd box. All going well as its just a bash script and bash is bash, however there is one line I'm unable to use directly, as bsd sed (correctly according to SUS at least, I believe[1]) appends a newline when writing to standard out, gnu sed doesnt. example BSD [backup@banshee ~]$ echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | sed -n 's/[[:space:]]*;[[:space:]]*/;/gp' /boot:7:1:5;/:7:1:5;/var:7:1:5 [backup@banshee ~]$ LINUX [backup@amber ~]$ echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | sed 's/[[:space:]]*;[[:space:]]*/;/g' /boot:7:1:5;/:7:1:5;/var:7:1:5[backup@amber ~]$ is there any easy way to make our sed do the same as gnu sed here? You could also just lop off the newline with tr -d '\n': echo -n "/boot:7:1:5; /:7:1:5; /var:7:1:5" | sed -n 's/[[:space:]]*;[[:space:]]*/;/gp' | tr -d '\n' ___ 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 Magnusson, 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 us. 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: sed vs gnu sed
Vincent Hoffman wrote: > bsd sed (correctly according to SUS at least, I believe[1]) > appends a newline when writing to standard out, gnu sed doesnt. The wonderful thing about standards is that there are so many to choose from -- Tanenbaum > is there any easy way to make our sed do the same as gnu sed here? As long as it is OK to remove _all_ newlines -- which seems to be the case here -- you could pipe the output through tr -d '\012' ___ 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: on uhub1 ums0: 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: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON % usbconfig -u 1 -a 2 dump_info ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE % dmesg | grep "^u[km]" ukbd1: on usbus1 ums0: 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: at usbus1, > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > % usbconfig -u 1 -a 2 dump_info > ugen1.2: at usbus1, > cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE > > % dmesg | grep "^u[km]" > ukbd1:class 0/0, rev 2.00/1.05, addr 3> on usbus1 > ums0: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"
RELENG_8 on AMX FX 8150?
Does anyone know if this works? I have had one kernel trap and a make buildworld fails with this: cc -O2 -pipe -I. -I/usr/src/lib/libdwarf -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/libdwarf/dwarf_errmsg.c cc: Internal error: Illegal instruction: 4 (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. I also have an error when trying to build gettext-0.18.1.1.tar.gz. It could be I have something corrupt, a bad disk, or whatever but it isn't obvious and I'm wondering whether anyone is working with that CPU. bd1# dmesg Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #0: Fri Oct 28 22:47:38 PDT 2011 root@:/usr/src/sys/amd64/compile/WORKHORSE amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD FX(tm)-8150 Eight-Core Processor(3616.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 15 Model = 1 Stepping = 2 Features=0x178bfbff Features2=0x1698220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant real memory = 12884901888 (12288 MB) avail memory = 12385927168 (11812 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cfca (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 19 at device 3.0 on pci0 pci1: on pcib1 mps0: port 0xee00-0xeeff mem 0xfddfc000-0xfddf,0xfdd8-0xfddb irq 19 at device 0.0 on pci1 mps0: Firmware: 07.00.00.00 mps0: IOCCapabilities: 185c mps0: [ITHREAD] pcib2: irq 16 at device 4.0 on pci0 pci2: on pcib2 em0: port 0xdf00-0xdf1f mem 0xfdbc-0xfdbd,0xfdb0-0xfdb7,0xfdbfc000-0xfdbf irq 16 at device 0.0 on pci2 em0: Using MSIX interrupts with 3 vectors em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:1b:21:c5:f0:6c pcib3: irq 17 at device 9.0 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: irq 16 at device 12.0 on pci0 pci4: on pcib4 mps1: port 0xbe00-0xbeff mem 0xfd1fc000-0xfd1f,0xfd18-0xfd1b irq 16 at device 0.0 on pci4 mps1: Firmware: 10.00.02.00 mps1: IOCCapabilities: 1285c mps1: [ITHREAD] pcib5: irq 17 at device 13.0 on pci0 pci5: on pcib5 vgapci0: port 0xae00-0xaeff mem 0xd000-0xdfff,0xfdec-0xfded irq 17 at device 0.0 on pci5 pci5: at device 0.1 (no driver attached) atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfdfff000-0xfdfff3ff irq 19 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.20 controller with 6 6Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ohci0: mem 0xfdffe000-0xfdffefff irq 18 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfdffd000-0xfdffd0ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 ohci1: mem 0xfdffc000-0xfdffcfff irq 18 at device 19.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0xfdffb000-0xfdffb0ff irq 17 at device 19.2 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci1 pci0: at device 20.0 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib6: at device 20.4 on pci0 pci6: on pcib6 ohci2: mem 0xfdffa000-0xfdffafff irq 18 at device 20.5 on pci0 ohci2: [ITHREAD] usbus4: on ohci2 pcib7: at device 21.0 on pci0 pci7: on pcib7 re0: port 0x8e00-0x8eff mem 0xfd4ff000-0xfd4f,0xfd4f8000-0xfd4fbfff irq 17 at device 0.0 on pci7 re0: Using 1 MSI-X message re0: Chip rev. 0x2c80 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 50:e5:49:45:54:46 re0: [ITHREAD]
Re: RELENG_8 on AMX FX 8150?
Never mind, mostly. It is obvious -- duh. Nonetheless, anyone using this CPU? I'm curious what you think. On Thu, 10 Nov 2011, Dennis Glatting wrote: Does anyone know if this works? I have had one kernel trap and a make buildworld fails with this: cc -O2 -pipe -I. -I/usr/src/lib/libdwarf -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/lib/libdwarf/dwarf_errmsg.c cc: Internal error: Illegal instruction: 4 (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. I also have an error when trying to build gettext-0.18.1.1.tar.gz. It could be I have something corrupt, a bad disk, or whatever but it isn't obvious and I'm wondering whether anyone is working with that CPU. bd1# dmesg Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #0: Fri Oct 28 22:47:38 PDT 2011 root@:/usr/src/sys/amd64/compile/WORKHORSE amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD FX(tm)-8150 Eight-Core Processor(3616.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 15 Model = 1 Stepping = 2 Features=0x178bfbff Features2=0x1698220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant real memory = 12884901888 (12288 MB) avail memory = 12385927168 (11812 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cfca (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 19 at device 3.0 on pci0 pci1: on pcib1 mps0: port 0xee00-0xeeff mem 0xfddfc000-0xfddf,0xfdd8-0xfddb irq 19 at device 0.0 on pci1 mps0: Firmware: 07.00.00.00 mps0: IOCCapabilities: 185c mps0: [ITHREAD] pcib2: irq 16 at device 4.0 on pci0 pci2: on pcib2 em0: port 0xdf00-0xdf1f mem 0xfdbc-0xfdbd,0xfdb0-0xfdb7,0xfdbfc000-0xfdbf irq 16 at device 0.0 on pci2 em0: Using MSIX interrupts with 3 vectors em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:1b:21:c5:f0:6c pcib3: irq 17 at device 9.0 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: irq 16 at device 12.0 on pci0 pci4: on pcib4 mps1: port 0xbe00-0xbeff mem 0xfd1fc000-0xfd1f,0xfd18-0xfd1b irq 16 at device 0.0 on pci4 mps1: Firmware: 10.00.02.00 mps1: IOCCapabilities: 1285c mps1: [ITHREAD] pcib5: irq 17 at device 13.0 on pci0 pci5: on pcib5 vgapci0: port 0xae00-0xaeff mem 0xd000-0xdfff,0xfdec-0xfded irq 17 at device 0.0 on pci5 pci5: at device 0.1 (no driver attached) atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfdfff000-0xfdfff3ff irq 19 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.20 controller with 6 6Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ohci0: mem 0xfdffe000-0xfdffefff irq 18 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfdffd000-0xfdffd0ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 ohci1: mem 0xfdffc000-0xfdffcfff irq 18 at device 19.0 on pci0 ohci1: [ITHREAD] usbus2: on ohci1 ehci1: mem 0xfdffb000-0xfdffb0ff irq 17 at device 19.2 on pci0 ehci1: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci1 pci0: at device 20.0 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib6: at device 20.4 on pci0 pci6: on pcib6 ohci2: mem 0xfdffa000-0xfdffafff irq 18 at device 20.5 on pci0 ohci2: [ITHREAD] usbus4: on ohci2 pcib7: at device 21.0 on pci0 pci7: on pcib7 re0: port 0x8e00-0x8eff mem 0xfd4ff000-0xfd4f,0xfd4f8000-0xfd4fbfff irq 17 at device 0.0 on pci7 re0: Using 1 MSI-X message re0: Chip rev. 0x2c80 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX,
php5-pgsql and postgresql 9.1.1
I'm trying to get the php5-pgsql module to work with postgresql 9.1.1, the current version in ports. It seems that when I install php5-pgsql from ports it depends on postgresql 8.4.9. I don't see anything in the Makefile that allows me to change this. How do I get the php5-pgsql port to see that I have postgres 9.1.1 installed? Rob ___ 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"
