Hello,
I have tested it. It is still working fine.
Regards,
Stef
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge
On Friday 03 June 2005 14:55, stef wrote:
> Hello,
>
> I tested the patch. It is working fine.
>
> Regards,
> Stef
>
Stephane,
Some more changes:
- when filling input_id structure convert USB descriptors (le16_to_cpu)
- driver_info field in usb_acecad_id_table was not set
Hello,
I tested the patch. It is working fine.
Regards,
Stef
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge trac
On Thursday 02 June 2005 23:13, Stéphane VOLTZ wrote:
> Dmitry Torokhov a écrit :
>
> >On 6/2/05, Stéphane VOLTZ <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Hello,
> >>
> >> I have removed these superfluous attributes and unused MISC things,
> >>added the dev.dev field.
> >>The gimp is working fin
Dmitry Torokhov a écrit :
On 6/2/05, Stéphane VOLTZ <[EMAIL PROTECTED]> wrote:
Hello,
I have removed these superfluous attributes and unused MISC things,
added the dev.dev field.
The gimp is working fine with this version of the module. Patch is attached.
Hi Stephane,
It looks li
On 6/2/05, Stéphane VOLTZ <[EMAIL PROTECTED]> wrote:
>Hello,
>
> I have removed these superfluous attributes and unused MISC things,
> added the dev.dev field.
> The gimp is working fine with this version of the module. Patch is attached.
>
Hi Stephane,
It looks like acecad_features struct
Dmitry Torokhov a écrit :
Hi Edouard,
On 6/1/05, Edouard TISSERANT <[EMAIL PROTECTED]> wrote:
Hi all.
Patch should be now OK.
It should fit to last Dimitry's requests.
Yes, it is much better now. I still have couple of concerns though:
+ acecad->dev.absmin[ABS_MISC] = 0
On Wed, 1 Jun 2005, Oliver Neukum wrote:
> > It's not so easy to synchronize operations on an attribute with driver
> > operations if the driver doesn't own the attribute's kobject. In this
>
> Are you suggesting that kobjects should have slaves whose refcounts
> they control?
No, not necessa
Am Mittwoch, 1. Juni 2005 22:29 schrieb Alan Stern:
> I'm not sure what more you would need beyond checking that dev.driver_data
> != NULL. If the device was physically disconnected then there's no
> problem -- once your driver's disconnect routine runs no other driver is
> allowed to bind to the
> > > On the other hand, remove methods typically do call dev_set_drvdata(dev,
> > > NULL). Thus a read-during-disconnect might very well end up with acecad
> > > == NULL, and so the check above is necessary.
> > >
> >
> > OK, consider this:
> >
> > CPU1:CPU2
>
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > Using a private semaphore for synchronization,
> > you can guarantee that dev.driver_data is NULL whenever your driver is
> > bound to the interface and the private data doesn't exist.
>
> BTW, you c
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> Using a private semaphore for synchronization,
> you can guarantee that dev.driver_data is NULL whenever your driver is
> bound to the interface and the private data doesn't exist.
BTW, you can't use private semaphore... Well, you can as long as i
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> > > Right. In serio/gameport code we take a lock and then check if
> > > currently bound driver is still "us". This way we can detect if device
> > > was switched to alternate driver. If it still the same driver we asume
> > > that the data returned is
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
>
> > On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > It's not so easy to synchronize operations on an attribute with driver
> > > operations if the driver doesn't own the attribute's kobject. In
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > It's not so easy to synchronize operations on an attribute with driver
> > operations if the driver doesn't own the attribute's kobject. In this
> > case there would have to be a single driver-wide s
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> It's not so easy to synchronize operations on an attribute with driver
> operations if the driver doesn't own the attribute's kobject. In this
> case there would have to be a single driver-wide semaphore protecting
> intf->dev.driver_data for all
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> >
> > > > +static ssize_t show_tabletSize(struct device *dev, char *buf)
> > > > +{
> > > > + struct usb_acecad *acecad = dev_get_drvdata(dev);
> >
On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
>
> > > +static ssize_t show_tabletSize(struct device *dev, char *buf)
> > > +{
> > > + struct usb_acecad *acecad = dev_get_drvdata(dev);
> > > +
> > > + if (acecad == NULL)
> > > +
On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> > +static ssize_t show_tabletSize(struct device *dev, char *buf)
> > +{
> > + struct usb_acecad *acecad = dev_get_drvdata(dev);
> > +
> > + if (acecad == NULL)
> > + return 0;
>
> This check - is it really needed? Attributes a
Hi Edouard,
On 6/1/05, Edouard TISSERANT <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> Patch should be now OK.
>
> It should fit to last Dimitry's requests.
>
Yes, it is much better now. I still have couple of concerns though:
> + acecad->dev.absmin[ABS_MISC] = 0;
> + acecad->dev.absmax
Hi all.
Patch should be now OK.
It should fit to last Dimitry's requests.
Here after is the mail of Stephane ( don't have time to translate it to
english ...)
Patch is attached to the mail.
Regards,
Edouard
---
Bonjour,
j'ai mis le driver à jour a
On Monday 30 May 2005 17:16, Edouard TISSERANT wrote:
> Staphane Voltz has fixed this points:
> - use usb_kill_urb
> - Leaking an urb in the error path
> - use SLAB_KERNEL
>
> Please download last version of the patch on SF.
>
> Regarding resource freeing in usb_acecad_disconnect() al
Staphane Voltz has fixed this points:
- use usb_kill_urb
- Leaking an urb in the error path
- use SLAB_KERNEL
Please download last version of the patch on SF.
Regarding resource freeing in usb_acecad_disconnect() all other driver
do the same. Are they all wrong ?
Regarding Open/Close
On Monday 30 May 2005 01:47, Oliver Neukum wrote:
> Am Montag, 30. Mai 2005 06:37 schrieb Dmitry Torokhov:
> > On Sunday 29 May 2005 10:23, Oliver Neukum wrote:
> > > Am Sonntag, 29. Mai 2005 15:42 schrieb Giuseppe Bilotta:
> > > > Hello all,
> > > >
> > > > I have a an Acecad/[EMAIL PROTECTED] gr
Am Montag, 30. Mai 2005 06:37 schrieb Dmitry Torokhov:
> On Sunday 29 May 2005 10:23, Oliver Neukum wrote:
> > Am Sonntag, 29. Mai 2005 15:42 schrieb Giuseppe Bilotta:
> > > Hello all,
> > >
> > > I have a an Acecad/[EMAIL PROTECTED] graphic tablet. There are drivers
> > > for it
> > > available
On Sunday 29 May 2005 10:23, Oliver Neukum wrote:
> Am Sonntag, 29. Mai 2005 15:42 schrieb Giuseppe Bilotta:
> > Hello all,
> >
> > I have a an Acecad/[EMAIL PROTECTED] graphic tablet. There are drivers for
> > it
> > available on the Internet (see for examples
> > http://acecad.sourceforge.net
Am Sonntag, 29. Mai 2005 15:42 schrieb Giuseppe Bilotta:
> Hello all,
>
> I have a an Acecad/[EMAIL PROTECTED] graphic tablet. There are drivers for it
> available on the Internet (see for examples
> http://acecad.sourceforge.net/ and the pages linked from there,
> although the wanadoo.fr page
27 matches
Mail list logo
