On Fri, May 02, 2003 at 16:34 +0200, Andreas Klemm wrote: > > I made a test installation of the last -current snapshot > from current.freebsd.org. > > [ ... ] > > 3. Strange behaviour of mouse klicks under X11, if moused is running > and you use /dev/sysmouse as mousedevice under X11. > Its a PS/2 mouse here. Configuring protocol ps/2 and using /dev/psm0 > works perfectly. > The strange behaviour is, that a mouseclick doesn't immediately > have an effect when clicking selections, next or o.k. buttons. > You not only have to release the klicked mouse butten, additionally > you have to move the mouse, so that the desired action is taken. > So moused seems to buffer mousevents or something "compareable". This is a two button mouse? With "emulate third button" enabled? In this case the behaviour is by design and cannot be changed. To summarize: It's assumed to have been an click with the third button when you press the two physically existent buttons together. As we all know, there's no such thing as "at the same time". To allow for jitter (humans are slow), the computer has to wait after seeing one down event for 1) the other button to come down or the pressed button to go up, 2) the mouse to move without other button events, or 3) a timeout without any of the button or motion events to happen. I don't know how long you have to wait between clicking and moving, but your timeout seems to be rather long. Wait a little longer and the computer will see by itself that it was just a single button press. :) As stated: this is by design and cannot be changed. See it as similar to the ESC key pressing in terminals (you don't know if it was just ESC or the start of a long sequence like function or cursor keys, so you have to wait what comes next or for a timeout to run into). All you may be able to do is to adjust the three button emulation timeout. Or even better -- plug in a pointing device with more than two buttons, X11 has had a real use for these buttons for several decades and you will even miss functionality with only two of them. The three button emulation is just a hack. > 4. All kernel processes in process status show in the column > "Started" the date: 1Jan70. I think this should be the time, > when the process has been started. This has been reported in this list. It's just that some processes start before the (OS internal) clock is set. That's why the start time is "the epoch". There was even a patch flying around which solved the problem (adjusted or corrected / set the start time information the first time the parameter gets listed and the clock has been set). Since it was a one liner it might have been committed already. > 5. I tried to mount the FreeBSD-current partitions under > FreeBSD-stable (latest 4.8-STABLE) > There goes something really wrong. > Mount doesn't complain when mounting, but when you try > to access /current by typing > cd /current > then you can't change into that directory. > You even DON'T see the mountpoint in the root directory anymore !!!! > And cd complains with: /current, not a directory. > You are able to unmount /current, and then you see again the > mountpoint (the directory /current). > You can mount and unmount /current without panics. > And /current always vanishes, if you mount this current filesystem > under stable. > Additional information, the -current root-fs has normal parameters, > as suggested by sysinstall, so softupdates are for example not enabled. > > Question: is this because of UFS2 in -current ??? It looks like it. Does your -STABLE version know about UFS2? Have you tried to "mount -o ro" the -CURRENT partitions to see if the rw mount has problems with updating (i.e. writing to) file systems it cannot handle? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig_at_gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.Received on Fri May 02 2003 - 09:19:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:06 UTC