headers
Dave Huang | 1 Jan 2004 07:55
Gravatar

Re: Wacom USB tablet and XF86 4.3.0?

[ moving from netbsd-help to tech-x11; see bottom of message for
  what's been going on ]

On Wed, Dec 31, 2003 at 11:43:16AM +0100, Lennart Augustsson wrote:
> Since the server is linked against libusbhid you'd think that
> the symbols should be found.  Do the symbols appear in libusbhid?

Yes, they're in libusbhid. I noticed that nm wasn't showing them in
the XFree86 binary though, so I put
-Wl,--whole-archive/no-whole-archive around -lusbhid. That got the
symbols included as undefined ("U" in the nm output), but I still got 
the unresolved symbol errors when starting X. So then I tried
-Wl,--whole-archive /usr/lib/libusbhid.a -Wl,--no-whole-archive; the
functions are now included in the XFree86 binary ("T" in the nm
output), but still getting unresolved symbols.

I have no clue how XF86's loader works... anyone have some thoughts on
why it's not finding the symbols?

> Dave Huang wrote:
> >On Mon, Dec 29, 2003 at 01:59:50PM +0100, Lennart Augustsson wrote:
> >
> >>The tablet support is not integrated in XF86 4.x yet.
> >>But OpenBSD has done it, so you can probably grab it from
> >>their X tree.
> >
> >
> >Perhaps this message is more appropriate for tech-x11... I got the
> >driver compiled, put usbtablet_drv.o in /usr/X11/lib/modules/input,
> >added the appropriate lines to my XF86Config file to load it, but it's
(Continue reading)

Permalink | Reply | 7 comments |
headers
Matthieu Herrb | 1 Jan 2004 10:00
Picon
Picon
Favicon

Re: Wacom USB tablet and XF86 4.3.0?

You wrote (in your message from Thursday 1)
 > [ moving from netbsd-help to tech-x11; see bottom of message for
 >   what's been going on ]
 > 
 > On Wed, Dec 31, 2003 at 11:43:16AM +0100, Lennart Augustsson wrote:
 > > Since the server is linked against libusbhid you'd think that
 > > the symbols should be found.  Do the symbols appear in libusbhid?
 > 
 > Yes, they're in libusbhid. I noticed that nm wasn't showing them in
 > the XFree86 binary though, so I put
 > -Wl,--whole-archive/no-whole-archive around -lusbhid. That got the
 > symbols included as undefined ("U" in the nm output), but I still got 
 > the unresolved symbol errors when starting X. So then I tried
 > -Wl,--whole-archive /usr/lib/libusbhid.a -Wl,--no-whole-archive; the
 > functions are now included in the XFree86 binary ("T" in the nm
 > output), but still getting unresolved symbols.
 > 
 > I have no clue how XF86's loader works... anyone have some thoughts on
 > why it's not finding the symbols?

The X server need to export the symbols to its modules. Look at the
following change in OpenBSD:

http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/xc/programs/Xserver/hw/xfree86/loader/xf86sym.c.diff?r1=1.3&r2=1.4

--

-- 
					Matthieu
Permalink | Reply | 6 comments |
headers
Dave Huang | 2 Jan 2004 00:25
Gravatar

Re: Wacom USB tablet and XF86 4.3.0?

On Thu, Jan 01, 2004 at 10:00:34AM +0100, Matthieu Herrb wrote:
> The X server need to export the symbols to its modules. Look at the
> following change in OpenBSD:
> 
> http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/xc/programs/Xserver/hw/xfree86/loader/xf86sym.c.diff?r1=1.3&r2=1.4

Ah, that was it, thanks!

Now the driver probably works, but I think there are two problems. The
first problem is that if I have the ums driver configured in my
kernel, it'll attach to the Graphire3, and wsmouse attaches to that. I
then no longer have a /dev/uhid0 to call USB_GET_REPORT_DESC on. If I
use /dev/wsmouse1 instead, it returns an "Invalid ioctl for device"
error. It looks like wsmouse doesn't recognize the ioctl, so it calls
ums_ioctl. ums doesn't recognize it either, so it returns EPASSTHOUGH.
I don't know what EPASSTHROUGH does, but it doesn't seem to be passing
it up to uhid, which would know what to do with the ioctl. I guess
this one belongs more on tech-kern than x11 though (I'm touring all
the mailing lists :) For now, I've commented ums out of my kernel:

uhidev0: WACOM CTE-430-UV3.1-4, rev 1.10/3.14, addr 2, iclass 3/1
uhidev0: 3 report ids
uhid0 at uhidev0 reportid 1: input=4, output=0, feature=0
uhid1 at uhidev0 reportid 2: input=7, output=0, feature=1
uhid2 at uhidev0 reportid 3: input=0, output=0, feature=1

But the main problem is that the driver doesn't seem to support the
Graphire3; when I start X, it now complains "/dev/uhid0 has no X, Y,
or In_Range report" (same complaint if I use uhid1 or uhid2). Looks
like the Graphire3 doesn't use the standard USB Digitizer reports?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Matthieu Herrb | 2 Jan 2004 08:35
Picon
Picon
Favicon

Re: Wacom USB tablet and XF86 4.3.0?

You wrote (in your message from Thursday 1)
 > On Thu, Jan 01, 2004 at 10:00:34AM +0100, Matthieu Herrb wrote:
 > > The X server need to export the symbols to its modules. Look at the
 > > following change in OpenBSD:
 > > 
 > > http://www.openbsd.org/cgi-bin/cvsweb.cgi/XF4/xc/programs/Xserver/hw/xfree86/loader/xf86sym.c.diff?r1=1.3&r2=1.4
 > 
 > Ah, that was it, thanks!
 > 
 > Now the driver probably works, but I think there are two problems. The
 > first problem is that if I have the ums driver configured in my
 > kernel, it'll attach to the Graphire3, and wsmouse attaches to that. I
 > then no longer have a /dev/uhid0 to call USB_GET_REPORT_DESC on. If I
 > use /dev/wsmouse1 instead, it returns an "Invalid ioctl for device"
 > error. It looks like wsmouse doesn't recognize the ioctl, so it calls
 > ums_ioctl. ums doesn't recognize it either, so it returns EPASSTHOUGH.
 > I don't know what EPASSTHROUGH does, but it doesn't seem to be passing
 > it up to uhid, which would know what to do with the ioctl. I guess
 > this one belongs more on tech-kern than x11 though (I'm touring all
 > the mailing lists :) For now, I've commented ums out of my kernel:
 > 
 > uhidev0: WACOM CTE-430-UV3.1-4, rev 1.10/3.14, addr 2, iclass 3/1
 > uhidev0: 3 report ids
 > uhid0 at uhidev0 reportid 1: input=4, output=0, feature=0
 > uhid1 at uhidev0 reportid 2: input=7, output=0, feature=1
 > uhid2 at uhidev0 reportid 3: input=0, output=0, feature=1
 > 
 > But the main problem is that the driver doesn't seem to support the
 > Graphire3; when I start X, it now complains "/dev/uhid0 has no X, Y,
 > or In_Range report" (same complaint if I use uhid1 or uhid2). Looks
(Continue reading)

Permalink | Reply | 4 comments |
headers
TAKEMURA Shin Takemura | 2 Jan 2004 12:34
Picon

Re: porting XF3 servers to XF4

Hi,

I've also succeeded in cross compiling Xhpc server for hpcmips and the
server runs some degree. At least, Xhpc, xterm, oclock, xload and twm
seems to be OK. Thank you, matthew!

I, however, found that system froze entirely when I tried ico. And I 
haven't even started native compile stuff.

Because Tyler seems to be working for Xhpc cross compiling, I'm sending
my patch instead of commiting into the repository. Please find the patch
and new files in the attachment.

modified files (Xhpc-src.diff and Xhpc-xsrc.diff):
---------------------------------------------------
M src/x11/Xserver/Makefile
M src/x11/Xserver/Xserver/Makefile
M src/x11/Xserver/Xserver/Makefile.Xserver
M src/x11/Xserver/hw/Makefile
M xsrc/xfree/xc/programs/Xserver/cfb/cfb8line.c
M xsrc/xfree/xc/programs/Xserver/cfb/cfbmskbits.h

new files (Xhpc-src-new.tgz):
---------------------------------------------------
A src/x11/Xserver/Xserver/Xhpc/Makefile
A src/x11/Xserver/Xserver/Xhpc/Xhpc.c
A src/x11/Xserver/hw/netbsd/hpc/Makefile
(And the patch for xc/programs/Xserver/hw/netbsd/hpc is Xhpc.diff)

For the change of cfb8line.c, please refer my change in XF3 tree,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tyler Retzlaff | 2 Jan 2004 13:02
Picon

Re: porting XF3 servers to XF4

On Fri, Jan 02, 2004 at 08:34:20PM +0900, TAKEMURA Shin Takemura wrote:
> Hi,
> 
> I've also succeeded in cross compiling Xhpc server for hpcmips and the
> server runs some degree. At least, Xhpc, xterm, oclock, xload and twm
> seems to be OK. Thank you, matthew!
> 
> Because Tyler seems to be working for Xhpc cross compiling, I'm sending
> my patch instead of commiting into the repository. Please find the patch
> and new files in the attachment.
> 

Hello, 

this all looks pretty good I'm perfectly happy with you committing
these changes the src/x11 patches you have are nearly identical to
what I have in my tree.  Also, the hpcarm & hpcsh ports can take
advantage of the xsrc changes.

The only things I might mention is that we don't necessarily have to
provide GetTime.c, OsVendorFatalError() or DPMS stubs they are
actually available in other libs but are only turned on (or needed) if
particular defines occur.  Though it may be cleaner in the long run to
duplicate them in hpc/.  Thoughts?

Great job!

Tyler R. Retzlaff <rtr <at> NetBSD.org> http://www.NetBSD.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Valeriy E. Ushakov | 2 Jan 2004 14:18
Picon

Re: porting XF3 servers to XF4

On Fri, Jan 02, 2004 at 23:02:39 +1100, Tyler Retzlaff wrote:

> > I've also succeeded in cross compiling Xhpc server for hpcmips and the
> > server runs some degree. At least, Xhpc, xterm, oclock, xload and twm
> > seems to be OK. Thank you, matthew!
> > 
> > Because Tyler seems to be working for Xhpc cross compiling, I'm sending
> > my patch instead of commiting into the repository. Please find the patch
> > and new files in the attachment.
> 
> this all looks pretty good I'm perfectly happy with you committing
> these changes the src/x11 patches you have are nearly identical to
> what I have in my tree.  Also, the hpcarm & hpcsh ports can take
> advantage of the xsrc changes.

Seconded.  I've tried to cross-compile Xhpc for hpcsh with Tyler's
uncommitted sources and the resulting server crashes b/c cfb's
devPrivate is not handled correctly, but at a glance the proposed
patches address this.  But tracking patches to patches for a file that
is not in the cvs is a pain in the behind.

So I'd say commit now, debug later ;).

Thanks.

SY, Uwe
--

-- 
uwe <at> ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen
(Continue reading)

Permalink | Reply | 0 comments |
headers
TAKEMURA Shin Takemura | 2 Jan 2004 14:23
Picon

Re: porting XF3 servers to XF4

Hi,

From: Tyler Retzlaff <rtr <at> netbsd.org>
Subject: Re: porting XF3 servers to XF4
Date: Fri, 2 Jan 2004 23:02:39 +1100

> > Because Tyler seems to be working for Xhpc cross compiling, I'm sending
> > my patch instead of commiting into the repository. Please find the patch
> > and new files in the attachment.
> 
> Hello, 
> 
> this all looks pretty good I'm perfectly happy with you committing
> these changes the src/x11 patches you have are nearly identical to
> what I have in my tree.  Also, the hpcarm & hpcsh ports can take
> advantage of the xsrc changes.
>
> The only things I might mention is that we don't necessarily have to
> provide GetTime.c, OsVendorFatalError() or DPMS stubs they are
> actually available in other libs but are only turned on (or needed) if
> particular defines occur.  Though it may be cleaner in the long run to
> duplicate them in hpc/.  Thoughts?

Did you already know the defines exactly? I feel that GetTime.c is
a little redundant.

Anyway, though I'm concerned about ico freeze, I will commit the changes 
once unless you object. I hope we can fix them later. 

What do you think?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Emmanuel Dreyfus | 2 Jan 2004 16:49
Picon

backspace and xterm

Hi

By default, xterm will get ^[[3~ when I hit backspace. This is unusable
with ksh, because ksh can only alias 3 characters, so bind -m
'^[[3~'='^H' won't work. After that command, backspace sends ^H~.

I fix the problem by doing a xmodmap -e "keysym Delete = 0x08", but the
question remain: why is the default unusable? I'm not an X11 expert, so
I have no idea why backspace generates ^[[3~ instead of just ^H, I'd
like to know.

--

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu <at> netbsd.org
Permalink | Reply | 0 comments |
headers
Dave Huang | 2 Jan 2004 20:57
Gravatar

Re: Wacom USB tablet and XF86 4.3.0?

On Fri, Jan 02, 2004 at 08:35:22AM +0100, Matthieu Herrb wrote:
> Well, this uhid0 device looks like a USB mouse. It explains :
> 1) why the device attaches as ums0 in the kernel
> 2) why the usbtablet driver doesn't grok it (it look for an In_range
>    usage in one of the inputs, which is missing there).
> 
> You should be able to use it under X by letting the kernel attach it
> as ums0 and configure an InputDevice section in XF86Config for
> /dev/wsmouse1 

Yes, I had mentioned in my first message to netbsd-help that it worked
fine as a mouse, but of course, it'd be much more useful as a tablet
with pressure sensitive and absolute positioning :)

> This hid looks more like a digitizer, however the Microsoft pages are
> of course not what the generic USB tablet driver expects. I don't have
> a graphire 3 available to try to decrypt the data in those pages.

I wonder if there's any chance that NetBSD is parsing the descriptor
incorrectly... I didn't look too closely, but it doesn't seem like the
Linux driver does anything different between a Graphire2 and a
Graphire3. I'll look around some more and see what I can find :)

> FYI, here's how a graphire 2 looks like:

Thanks... does a Graphire2 have multiple HID reports, or only that one?
--

-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym <at> azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
(Continue reading)

Permalink | Reply | 3 comments |

Gmane