Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons
Andre, --- André-Philippe Paquet [EMAIL PROTECTED] wrote: My MX500 is working just fine. Here what I do: - Install imwheel (/usr/ports/x11/imwheel) - Add this to ~/.imwheelrc .* None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 (null) None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 - In my x.org http://x.org file.. For the InputDevice section: Option Buttons 7 Option ZAxisMapping 6 7 - Finaly, I run these two commands on Xwindows start: imwheel -b 67 xmodmap -e pointer = 1 2 3 6 7 4 5 Nope. I reproduced these same settings _exactly_, and they produce the same results. With your settings above, the scroll wheel works fine, and the two thumb buttons each cause the web page to scroll very slightly downward. This is the same thing they did with all the other different configurations I tried. Why is using mouse thumb buttons under FreeBSD _rocket science_ ? Why is this a _hard problem_ ? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
logitech mx700 mouse button disfunction under FreeBSD
The logitech mx700 is a cordless 10-button mouse (3 buttons, two thumb buttons, scroll wheel up and down, two paging buttons, and one app button). While the mx500 mouse, that seems to be very closely related to the mx700, has been reported to work (scroll wheel and both thumb buttons function) under FreeBSD, and while the mx700 is working in the same fashion under linux, the mx700 _does not_ function under FreeBSD. Details: Using this configuration in your X/Xorg configuration file: Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/sysmouse Option Buttons 7 Option ZAxisMapping 6 7 EndSection along with these startup options for X/Xorg: /usr/X11R6/bin/xmodmap -e pointer = 1 2 3 6 7 4 5 /usr/X11R6/bin/imwheel -b 67 and these settings in ~/.imwheelrc : .* None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 (null) None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 You will end up with the three standard buttons functioning, and the scrollwheel functioning (as buttons events 4 and 5). Further, the page up and down buttons will simply send double-4 and double-5 button events. However, the other three buttons (thumbs and app button) will _all send button event 5_. I have tried every conceivable combination of Zaxismapping, xmodmap settings, and with and without imwheel ... no matter what, the three final buttons (two thumbs and one app button) always produce the same button event. Even if you configure 9 or 10 buttons in your X config. Those three buttons will ALWAYS send the same button event. So what is the reason for this ? Why does the mx500 function and the mx700 does not ? More importantly, what is a strategy for getting to the bottom of this and fixing it ? If you look at the mailing list archives, there are many, many examples of people going through this same hell and just giving up. Comments ? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons
Sorry, I didn't see your last message! Start xwindows with your favorite wm and in a terminal, run: imwheel -b 67 xmodmap -e pointer = 1 2 3 6 7 4 5 If it doesn't work, it may be something else. I just redid the whole process I told and it works here. Andre-Philippe On 7/5/05, Joe Schmoe [EMAIL PROTECTED] wrote: Andre, --- André-Philippe Paquet [EMAIL PROTECTED] wrote: My MX500 is working just fine. Here what I do: - Install imwheel (/usr/ports/x11/imwheel) - Add this to ~/.imwheelrc .* None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 (null) None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 - In my x.org http://x.org http://x.org file.. For the InputDevice section: Option Buttons 7 Option ZAxisMapping 6 7 - Finaly, I run these two commands on Xwindows start: imwheel -b 67 xmodmap -e pointer = 1 2 3 6 7 4 5 Nope. I reproduced these same settings _exactly_, and they produce the same results. With your settings above, the scroll wheel works fine, and the two thumb buttons each cause the web page to scroll very slightly downward. This is the same thing they did with all the other different configurations I tried. Why is using mouse thumb buttons under FreeBSD _rocket science_ ? Why is this a _hard problem_ ? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Call for FreeBSD status reports
All, Three month of fruitful development have passed since the last round of FreeBSD status reports, and the release of FreeBSD 6.0 is on the doorstep. We hope that you made good progress on your projects and have interesting news to share. Please do so by sending a status report to [EMAIL PROTECTED] Submissions are due by July 15, 2005. Reports should cover activities during May to June, but may of course cover earlier work as well. In addition we encourage you to use the Open Tasks section to recruit help for your project and point out future direction. Submissions are *not* limited to FreeBSD developers with commit rights! It is open to everybody who is doing FreeBSD related work and wants to share progress with the community. The status reports are also a good vehicle to gather interested people for you WIP. We have introduced a new category called soc to pool reports related to Google Summer of Code. We hope for interesting news from that corner! To help you with fileing your report you will find a webform or xml-template linked from http://www.freebsd.org/news/status/ (as soon as the www build completes). Submissions are due on July 15. Thanks a lot, and we are hoping for a big turn-out. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp7bIJEEAJ4k.pgp Description: PGP signature
Re: linking libjava.so RPATH problem
On 7/5/05, Vasil Dimov [EMAIL PROTECTED] wrote: On Tue, Jul 05, 2005 at 03:55:26PM -0600, Tom Schutter wrote: I am having problems linking in the Java JVM libraries (libjava.so, libverify.so, libjvm.so) into my executable. With these options added to my gcc command: -L/usr/local/jdk1.4.2/jre/lib/i386 -ljava -lverify -L/usr/local/jdk1.4.2/jre/lib/i386/server -ljvm It links ok, but when I try to run it I get: $ ./testme /libexec/ld-elf.so.1: Shared object libjava.so not found, required by testme At this point ldd tells me: $ ldd testme testme: libm.so.3 =3D /lib/libm.so.3 (0x2807c000) libjava.so =3D not found (0x0) libverify.so =3D not found (0x0) libjvm.so =3D not found (0x0) libpthread.so.1 =3D /usr/lib/libpthread.so.1 (0x28097000) libc.so.5 =3D /lib/libc.so.5 (0x280bb000) Using -Xlinker -rpath -Xlinker PATH_TO_JRE_DIR, I can tell my executable to look in the JRE dir for libjvm.so. I have verified that RPATH has been set in the executable using objdump: $ objdump -x testme | grep RPATH RPATH /usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server But when I run the executable, it cannot find libjvm.so: $ ./testme /libexec/ld-elf.so.1: Shared object libjvm.so not found, required by libjava.so At this point ldd tells me: $ ldd ./testme ./testme: libm.so.3 =3D /lib/libm.so.3 (0x2807c000) libjava.so =3D /usr/local/jdk1.4.2/jre/lib/i386/libjava.so (0x28097000) libverify.so =3D /usr/local/jdk1.4.2/jre/lib/i386/libverify.so (0x280b5000) libjvm.so =3D /usr/local/jdk1.4.2/jre/lib/i386/server/libjvm.so (0x280ca000) libpthread.so.1 =3D /usr/lib/libpthread.so.1 (0x28702000) libc.so.5 =3D /lib/libc.so.5 (0x28726000) libjvm.so =3D not found (0x0) libverify.so =3D not found (0x0) libjvm.so =3D not found (0x0) libstdc++.so.4 =3D /usr/lib/libstdc++.so.4 (0x2880) Note that at this point on Linux, testme runs ok. If I set LD_LIBRARY_PATH, the libraries are found (no output is correct): $ LD_LIBRARY_PATH=3D/usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/server ./testme $ My questions are: 1) Why is the RPATH in the executable being ignored? Here are my suggestions: It is not being ignored, as you see: libjava.so, libverify.so and libjvm.so were found in /usr/local/jdk1.4.2/jre/lib/i386/ 2) When I add the -rpath, I get two copies of a libjvm.so reference in testme, one that resolves correctly, and one that doesn't. Why? What happens is that libjava.so depends on libjvm.so and libverify.so itself: % ldd /usr/local/jdk1.4.2/jre/lib/i386/libjava.so /usr/local/jdk1.4.2/jre/lib/i386/libjava.so: libjvm.so = not found (0x0) libverify.so = not found (0x0) and libverify.so depends on libjvm.so itself: % ldd /usr/local/jdk1.4.2/jre/lib/i386/libverify.so /usr/local/jdk1.4.2/jre/lib/i386/libverify.so: libjvm.so = not found (0x0) So, after finding libjava.so, libverify.so and libjvm.so, required by testme executable (thanks to its RPATH) the linker sees that libjava.so itself depends on libjvm.so and libverify.so and: 1. does not notice that they are already found/loaded 2. does not use the rpath in testme 3. starts looking for them in the standard path and does not find them 3) What is the correct way of linking in libjvm.so? In my point of view the libjava.so and libverify.so shared objects are incorrect in the way that they depend on some shared objects, that are not located in the standard path *AND* libjava.so and libverify.so do not have RPATH in themselves. 1. Recompile libjava.so and libverify.so without -L... -l..., it is not needed anyway. OR 2. Recompile libjava.so and libverify.so with -L... -l..., but also add -rpath OR 3. Use ldconfig -m (see ldconfig_paths in rc.conf(5)) OR 4. Use LD_LIBRARY_PATH Thanks, -- Tom Schutter This is making more sense now. 1) Does the fact that the linker does not realize that the libraries have already been found indicate a bug in the linker? If so, how do I best report it? 2) Because libjava.so and libverify.so were compiled by the java/jdk14 port, your suggestions on recompiling those libraries should be done within that framework. (This part is for you Alexey). 3) For now, I will try using ldconfig, but I think that the better solution is to fix the creation of the shared libraries. -- Tom Schutter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
bus error in strsep
Hello hackers,
I am getting a bus error in my application when I call strsep
and it matches a character. It doesn't matter whether I call
the strsep from my libc or a freshly compiled one, the error
stays the same.
This is my test case:
$ cat strsep.c
#define NULL ((void*)0)
/* copied verbatim from /usr/src/lib/libc/string/strsep.c,
* except for the name change
*/
char *
mystrsep(stringp, delim)
char **stringp;
const char *delim;
{
char *s;
const char *spanp;
int c, sc;
char *tok;
if ((s = *stringp) == NULL)
return (NULL);
for (tok = s;;) {
c = *s++;
spanp = delim;
do {
if ((sc = *spanp++) == c) {
if (c == 0)
s = NULL;
else
s[-1] = 0;
*stringp = s;
return (tok);
}
} while (sc != 0);
}
/* NOTREACHED */
}
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
(void*)mystrsep(c, :);
}
$ gcc -g -o strsep strsep.c
$ gdb strsep
gnu license
(gdb) run
Starting program: /home/stsp/test/strsep
Program received signal SIGBUS, Bus error.
0x080484f2 in mystrsep (stringp=0xbfbfea34, delim=0x80485e6 :) at strsep.c:26
26 s[-1] = 0;
(gdb) print s[-1]
$1 = 58 ':'
(gdb)
When I single step through mystrsep the program works fine.
I am running FreeBSD-current from 17th June 2005 on an Athlon-XP,
no SMP involved. I can reproduce the error on a dual Celeron box
running FreeBSD-5.4-RELEASE with SMP.
And I also get the same error with similar code using strtok.
Can anyone else reproduce this?
thanks a lot,
--
stefan
http://stsp.in-berlin.de PGP Key: 0xF59D25F0
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
Stefan,
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write
into it. replace it with
char *c = strdup(whats:your:name:buddy?);
(void*)mystrsep(c, :);
}
and it should work.
thanks,
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
Maksim Yevmenkin wrote:
Stefan,
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write into it.
replace it with
made type. that should read that is read only copy :)
char *c = strdup(whats:your:name:buddy?);
(void*)mystrsep(c, :);
}
and it should work.
thanks,
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
On Wed, Jul 06, 2005 at 12:10:23PM -0700, Maksim Yevmenkin wrote: Maksim Yevmenkin wrote: char *c = whats:your:name:buddy?; that is not read only copy. you can not write into it. replace it with made type. that should read that is read only copy :) Dark corners of C... So it's my own fault, as usual :) thanks a lot :) -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
On 2005-07-06 at 21:41:00 Stefan Sperling wrote: char *c = whats:your:name:buddy?; made type. that should read that is read only copy :) Dark corners of C... So it's my own fault, as usual :) Actually, this dark corner was enlightened not so long ago. String constants used to be writable for years, until someone decided that it was better not to. :) Anyway, you can get the old (deprecated!) behaviour by using the -fwritable-strings option to gcc. pgpOjDCRlF0Rw.pgp Description: PGP signature
Re: Using a logitech mx700 with scrollwheel _and_ thumb buttons
Joe Schmoe wrote: Andre, --- André-Philippe Paquet [EMAIL PROTECTED] wrote: My MX500 is working just fine. Here what I do: - Install imwheel (/usr/ports/x11/imwheel) - Add this to ~/.imwheelrc .* None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 (null) None, Up, Alt_L|Left,1 None, Down, Alt_L|Right,1 - In my x.org http://x.org file.. For the InputDevice section: Option Buttons 7 Option ZAxisMapping 6 7 - Finaly, I run these two commands on Xwindows start: imwheel -b 67 xmodmap -e pointer = 1 2 3 6 7 4 5 Nope. I reproduced these same settings _exactly_, and they produce the same results. With your settings above, the scroll wheel works fine, and the two thumb buttons each cause the web page to scroll very slightly downward. This is the same thing they did with all the other different configurations I tried. Why is using mouse thumb buttons under FreeBSD _rocket science_ ? Why is this a _hard problem_ ? because no-one who has the interest in fixing it has the time to do so and visa versa. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
On 2005-07-06 12:08, Maksim Yevmenkin [EMAIL PROTECTED] wrote:
Stefan,
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write
into it. replace it with
char *c = strdup(whats:your:name:buddy?);
Or the following:
char c[] = whats:your:name:buddy?;
which doesn't require a free() operation when you're done with c[].
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
that is not read only copy. you can not write
into it. replace it with
char *c = strdup(whats:your:name:buddy?);
Or the following:
char c[] = whats:your:name:buddy?;
which doesn't require a free() operation when you're done with c[].
actually it still will crash :)
beetle% cat 5.c
#include string.h
int
main(int argc, char* argv[])
{
char c[] = whats:your:name:buddy?;
strsep((char **) c, :);
return (0);
}
beetle% gcc -Wall -ggdb 5.c
beetle% ./a.out
Segmentation fault (core dumped)
so something like this
#include string.h
int
main(int argc, char* argv[])
{
char c[] = whats:your:name:buddy?, *s = c;
strsep((char **) s, :);
return (0);
}
will work too.
max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: thread-safe popen
Hi ,
Please find the code snippet of popen() from the source code that I
have (We are working on an OS that is derived from FreeBSD 4.1) . I
don't think I have the thread safe version .
-
FILE *
popen(command, type)
const char *command, *type;
{
struct pid *cur;
FILE *iop;
int pdes[2], pid, twoway;
char *argv[4];
struct pid *p;
/*
* Lite2 introduced two-way popen() pipes using socketpair().
* FreeBSD's pipe() is bidirectional, so we use that.
*/
if (strchr(type, '+')) {
twoway = 1;
type = r+;
} else {
twoway = 0;
if ((*type != 'r' *type != 'w') || type[1])
return (NULL);
}
if (pipe(pdes) 0)
return (NULL);
if ((cur = malloc(sizeof(struct pid))) == NULL) {
(void)_close(pdes[0]);
(void)_close(pdes[1]);
return (NULL);
}
argv[0] = sh;
argv[1] = -c;
argv[2] = (char *)command;
argv[3] = NULL;
switch (pid = vfork()) {
case -1:/* Error. */
(void)_close(pdes[0]);
(void)_close(pdes[1]);
free(cur);
return (NULL);
/* NOTREACHED */
case 0: /* Child. */
if (*type == 'r') {
/*
* The dup2() to STDIN_FILENO is repeated to avoid
* writing to pdes[1], which might corrupt the
* parent's copy. This isn't good enough in
* general, since the _exit() is no return, so
* the compiler is free to corrupt all the local
* variables.
*/
(void)_close(pdes[0]);
if (pdes[1] != STDOUT_FILENO) {
(void)dup2(pdes[1], STDOUT_FILENO);
(void)_close(pdes[1]);
if (twoway)
(void)dup2(STDOUT_FILENO, STDIN_FILENO);
} else if (twoway (pdes[1] != STDIN_FILENO))
(void)dup2(pdes[1], STDIN_FILENO);
} else {
if (pdes[0] != STDIN_FILENO) {
(void)dup2(pdes[0], STDIN_FILENO);
(void)_close(pdes[0]);
}
(void)_close(pdes[1]);
}
for (p = pidlist; p; p = p-next) {
(void)_close(fileno(p-fp));
}
execve(_PATH_BSHELL, argv, environ);
_exit(127);
/* NOTREACHED */
}
---
}
--
We had cases where our RAID applications (multi-threaded ) failed
with invocations of popen() . Initially we handpicked the popen()
calls and replaced it with actual code of the functions but it was
simply too much work and little gain .
So we decided to backport a thread-safe version . (If the above code
is not thread-safe then we will have a bigger problem at hand .)
--Dip
On 7/5/05, Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Jul 05), Dipjyoti Saikia said:
I am working on an OS derived for BSD 4.1 . I am trying to backport
a thread-safe version of popen() from BSD 4.10 .
popen should be threadsafe as of rev 1.17 (2003-01-03) of
/usr/src/lib/libc/gen/popen.c . It was merged into the 4.* branch in
rev 1.14.2.1 (2004/12/15). The PR is bin/50770 . Do you have a
testcase that causes it to fail?
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
