Re: small cleanup xf86-input-mouse
On Mon, Nov 22, 2010 at 07:42:35PM +, Miod Vallat wrote: Now SunMouse works through wsmouse(sunms add miod@ 20 May 2009) so we can remove our patch to SunMouse for xf86-input-mouse. I am not sure this is something we want to do. This code is third-party, and it does not hurt to keep the ability to run on older kernels. The sunmouse protocol decoder is a local addition (it was added by millert@ back in 2002 and never merged upstreams. http://www.openbsd.org/cgi-bin/cvsweb/XF4/xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c.diff?r1=1.4;r2=1.5 Ah! Then my objection no longer stands. Miod Do I understand correctly, there is no objection? OK? -- Alexandr Shadchin
Re: update pms driver
On Mon, Nov 22, 2010 at 09:44:14PM +, Nicholas Marriott wrote: Hi Alexandr This works fine for me with both with X and wsmoused. A few things: - Did you deliberately remove WSMOUSEIO_SRES? Yes. WSMOUSEIO_SRES in Xenocara not used, in src - only wsmoused and wsconsctl, in drivers - only in pms. I think that now do not need WSMOUSEIO_SRES. - Do we know what the XFree86 bug was and is it now fixed? Or do the PMS_PS2_XNEG/YNEG flags make the bounding unnecessary? In current X.org this error is not observed. - dz = (char)sc-packet[3]; -- shouldn't this be (signed char)? Exactly. I'll correct. - So we now call wsmouse_input even if the buttons haven't changed. This is fine, right? Previously wsmouse_input also called if the buttons were not changed, but there were some increment x, y or z. I just removed the unnecessary check for changes. If packet came from a mouse, it means that something has changed, check is not needed. I take it the overall aim of this is to make it easier to add additional mice types in future? Yes -- Alexandr Shadchin
Re: More Canon scanners (usbdevs, uscanner.c)
On Sat, Jul 1, 2006 at 12:38 PM, Miod Vallat m...@online.fr wrote:
This diff add support for more Canon scanners in -current (from
NetBSD). Tested on i386 with a CanoScan Lide 30:
Applied. Thanks!
Miod
Hi all,
Don't know what I drank at this time but it wasn't good at all for my brain.
I'd like to know if people are able to use their Canon scanner with
xsane via uscanner, because I can't with my Canon Lide 30.
So... if people have the same problems that I'm facing with Canon
scanners, I propose to completely revert the uscanner.c commit (rev
1.21).
Or if it's just with my device, I propose this patch which let me scan
content with xsane:
Index: uscanner.c
===
RCS file: /cvs/src/sys/dev/usb/uscanner.c,v
retrieving revision 1.43
diff -u -p -r1.43 uscanner.c
--- uscanner.c 24 Sep 2010 08:33:59 - 1.43
+++ uscanner.c 23 Nov 2010 20:36:35 -
@@ -94,7 +94,6 @@ static const struct uscan_info uscanner_
{{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N656U }, 0 },
{{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N670U }, 0 },
{{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1220U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1240U }, 0 },
/* Kye */
{{ USB_VENDOR_KYE, USB_PRODUCT_KYE_VIVIDPRO }, 0 },
--
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.
Re: More Canon scanners (usbdevs, uscanner.c)
I'd like to know if people are able to use their Canon scanner with xsane via uscanner, because I can't with my Canon Lide 30. So... if people have the same problems that I'm facing with Canon scanners, I propose to completely revert the uscanner.c commit (rev 1.21). Could this be caused by changes in the kernel and/or in xsane? Did you try e.g. an older xsane against a kernel which attaches your hardware as uscanner, and against a kernel with the uscanner.c chunk reverted? Miod
Re: More Canon scanners (usbdevs, uscanner.c)
On Tue, Nov 23, 2010 at 10:51 PM, Miod Vallat m...@online.fr wrote: Could this be caused by changes in the kernel and/or in xsane? Did you try e.g. an older xsane against a kernel which attaches your hardware as uscanner, and against a kernel with the uscanner.c chunk reverted? In fact, if my memory serves me right, I've never been able to use my scanner with uscanner (I have this device since years). I always had to disable uscanner at boot time, let the device attach as ugen, and run xsane. Then xsane works like a charm. When this devices attaches as uscanner, xsane is not able to detect the scanner. -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can.
Re: More Canon scanners (usbdevs, uscanner.c)
On Tue, 23 Nov 2010, Mattieu Baptiste wrote: On Tue, Nov 23, 2010 at 10:51 PM, Miod Vallat m...@online.fr wrote: Could this be caused by changes in the kernel and/or in xsane? Did you try e.g. an older xsane against a kernel which attaches your hardware as uscanner, and against a kernel with the uscanner.c chunk reverted? In fact, if my memory serves me right, I've never been able to use my scanner with uscanner (I have this device since years). I always had to disable uscanner at boot time, let the device attach as ugen, and run xsane. Then xsane works like a charm. ... Yes, this is the prefered way to do it. And xsane had nothing to do with it, libsane from sane-backends is what is accessing your device. At one point, the best would be to remove uscanner entirely as it's impossible to keep track of all devices anyway. IIRC at least Linux and FreeBSD now use libusb with sane for scanning (which is what you are doing when you disable uscanner). Cheers! -- Antoine
