Re: [PATCH]is_power_of_2-kernel/kfifo.c
On Thu, Jun 14, 2007 at 04:05:06PM +0530, vignesh babu wrote: > > > Replacing (n & (n-1)) in the context of power of 2 checks > with is_power_of_2 > > Signed-off-by: vignesh babu <[EMAIL PROTECTED]> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Thanks, Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]is_power_of_2-kernel/kfifo.c
On Thu, Jun 14, 2007 at 04:05:06PM +0530, vignesh babu wrote: Replacing (n (n-1)) in the context of power of 2 checks with is_power_of_2 Signed-off-by: vignesh babu [EMAIL PROTECTED] Signed-off-by: Stelian Pop [EMAIL PROTECTED] Thanks, Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le mardi 12 juin 2007 à 21:21 -0500, Nelson Castillo a écrit : > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote: > > Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit : > > > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote: > > > (cut) > > > > accessing userspace memory with a spinlock taken (moreover an > > > > irqsave() > > > > one) is bad bad bad. > > > > > > Hi Stelian. > > > > > > I'm sending the new patch without kfifo_put_user and kfifo_get_user. > > > > Ok, I have a few formatting/documentation comments: > > Applied, thanks. > > > Other than that I'm ok with this patch. > > Submitting. > > Regards, Nelson.- > > Signed-off-by: Nelson Castillo <[EMAIL PROTECTED]> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Thanks, Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le mardi 12 juin 2007 à 21:21 -0500, Nelson Castillo a écrit : On 6/12/07, Stelian Pop [EMAIL PROTECTED] wrote: Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit : On 6/12/07, Stelian Pop [EMAIL PROTECTED] wrote: (cut) accessing userspace memory with a spinlock taken (moreover an irqsave() one) is bad bad bad. Hi Stelian. I'm sending the new patch without kfifo_put_user and kfifo_get_user. Ok, I have a few formatting/documentation comments: Applied, thanks. Other than that I'm ok with this patch. Submitting. Regards, Nelson.- Signed-off-by: Nelson Castillo [EMAIL PROTECTED] Signed-off-by: Stelian Pop [EMAIL PROTECTED] Thanks, Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit : > On 6/12/07, Stelian Pop <[EMAIL PROTECTED]> wrote: > (cut) > > accessing userspace memory with a spinlock taken (moreover an > > irqsave() > > one) is bad bad bad. > > Hi Stelian. > > I'm sending the new patch without kfifo_put_user and kfifo_get_user. Ok, I have a few formatting/documentation comments: > + * This function copies at most @len bytes from the @buffer into > + * the FIFO depending on the free space, and returns the number of > + * bytes copied. ... or -EFAULT if copy_from_user fails > + * > + * Note that with only one concurrent reader and one concurrent > + * writer, you don't need extra locking to use these functions. > + */ > +int __kfifo_put_user(struct kfifo *fifo, const unsigned char __user *buffer, > + unsigned int len) spacing ? > + if(copy_from_user(fifo->buffer + (fifo->in & (fifo->size - 1)), > + buffer, l)) leave a space after the if please > + * This function copies at most @len bytes from the FIFO into the > + * @buffer and returns the number of copied bytes. or -EFAULT > + * > + * Note that with only one concurrent reader and one concurrent > + * writer, you don't need extra locking to use these functions. > + */ > + > +int __kfifo_get_user(struct kfifo *fifo, > + unsigned char __user *buffer, unsigned int len) spacing. Other than that I'm ok with this patch. Thanks, Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le lundi 11 juin 2007 à 16:26 -0500, Nelson Castillo a écrit : > Hi. > > I just added support for user space buffers in kfifo. I found useful > __kfifo_get_user to copy data to a user buffer in a read call. I didn't > like the idea of having an extra buffer. > > * Is it ok to add this support? I suppose it is, however: > + spin_lock_irqsave(fifo->lock, flags); > + > + ret = __kfifo_put_user(fifo, buffer, len); > + > + spin_unlock_irqrestore(fifo->lock, flags); [...] > +int __kfifo_put_user(struct kfifo *fifo, const unsigned char __user *buffer, > + unsigned int len) [...] > + if(copy_from_user(fifo->buffer + (fifo->in & (fifo->size - 1)), > + buffer, l)) > + return -EFAULT; [...] accessing userspace memory with a spinlock taken (moreover an irqsave() one) is bad bad bad. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le lundi 11 juin 2007 à 16:26 -0500, Nelson Castillo a écrit : Hi. I just added support for user space buffers in kfifo. I found useful __kfifo_get_user to copy data to a user buffer in a read call. I didn't like the idea of having an extra buffer. * Is it ok to add this support? I suppose it is, however: + spin_lock_irqsave(fifo-lock, flags); + + ret = __kfifo_put_user(fifo, buffer, len); + + spin_unlock_irqrestore(fifo-lock, flags); [...] +int __kfifo_put_user(struct kfifo *fifo, const unsigned char __user *buffer, + unsigned int len) [...] + if(copy_from_user(fifo-buffer + (fifo-in (fifo-size - 1)), + buffer, l)) + return -EFAULT; [...] accessing userspace memory with a spinlock taken (moreover an irqsave() one) is bad bad bad. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/1] support for user-space buffers in kfifo
Le mardi 12 juin 2007 à 11:24 -0500, Nelson Castillo a écrit : On 6/12/07, Stelian Pop [EMAIL PROTECTED] wrote: (cut) accessing userspace memory with a spinlock taken (moreover an irqsave() one) is bad bad bad. Hi Stelian. I'm sending the new patch without kfifo_put_user and kfifo_get_user. Ok, I have a few formatting/documentation comments: + * This function copies at most @len bytes from the @buffer into + * the FIFO depending on the free space, and returns the number of + * bytes copied. ... or -EFAULT if copy_from_user fails + * + * Note that with only one concurrent reader and one concurrent + * writer, you don't need extra locking to use these functions. + */ +int __kfifo_put_user(struct kfifo *fifo, const unsigned char __user *buffer, + unsigned int len) spacing ? + if(copy_from_user(fifo-buffer + (fifo-in (fifo-size - 1)), + buffer, l)) leave a space after the if please + * This function copies at most @len bytes from the FIFO into the + * @buffer and returns the number of copied bytes. or -EFAULT + * + * Note that with only one concurrent reader and one concurrent + * writer, you don't need extra locking to use these functions. + */ + +int __kfifo_get_user(struct kfifo *fifo, + unsigned char __user *buffer, unsigned int len) spacing. Other than that I'm ok with this patch. Thanks, Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PREEMPT_RT + HRT latencies on x86_64 SMP.
Hi, I have a dual Opteron dual-core machine here and while it behaves quite well on PREEMPT_RT when using the clock_nanosleep() tests, it doesn't work so well when using the timer primitives. I ran the tests on 2.6.20-rc6-rt6 - using the precompiled x86_64 kernel from Ingo's yum repository. The box is running RHEL 4, libc 2.3.4. The latencies are reproductible even without any specific load and even when using cyclictest on one or two threads only: ./cyclictest -b 1 -t 2 -p 90 1) a standard run gives a few latencies, like in: 0.57 0.16 0.32 1/150 3754 T: 0 ( 3732) P:90 I:1000 C: 10109 Min: 46 Act: 95 Avg: 93 Max: 240 T: 1 ( 3733) P:89 I:1500 C: 6741 Min: 52 Act: 92 Avg: 93 Max: 178 Are the maximum latencies observed here (values around 200-300 us are common) the expected ones ? Or are they caused by some problems which needs to be investigated ? 2) some big latencies (>10 ms) are observed in some conditions. I haven't been able to point out exactly what external activity - if any - causes this, but it seems to happen every 10 minutes or so : 1.82 1.86 1.53 6/150 3658 T: 0 ( 3621) P:90 I:1000 C:1596828 Min: 20 Act: 25 Avg: 93 Max: 512 T: 1 ( 3622) P:89 I:1500 C:1064525 Min: 53 Act: 95 Avg: 94 Max: 15586 I have captured a latency trace for the above run (using cyclictest -b as shown above), but I'm not sure it makes much sense. It weights almost 4 MB, so I'll not put in inline, get it from: http://www.popies.net/tmp/latency-trace-1 Any idea ? Thanks, -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PREEMPT_RT + HRT latencies on x86_64 SMP.
Hi, I have a dual Opteron dual-core machine here and while it behaves quite well on PREEMPT_RT when using the clock_nanosleep() tests, it doesn't work so well when using the timer primitives. I ran the tests on 2.6.20-rc6-rt6 - using the precompiled x86_64 kernel from Ingo's yum repository. The box is running RHEL 4, libc 2.3.4. The latencies are reproductible even without any specific load and even when using cyclictest on one or two threads only: ./cyclictest -b 1 -t 2 -p 90 1) a standard run gives a few latencies, like in: 0.57 0.16 0.32 1/150 3754 T: 0 ( 3732) P:90 I:1000 C: 10109 Min: 46 Act: 95 Avg: 93 Max: 240 T: 1 ( 3733) P:89 I:1500 C: 6741 Min: 52 Act: 92 Avg: 93 Max: 178 Are the maximum latencies observed here (values around 200-300 us are common) the expected ones ? Or are they caused by some problems which needs to be investigated ? 2) some big latencies (10 ms) are observed in some conditions. I haven't been able to point out exactly what external activity - if any - causes this, but it seems to happen every 10 minutes or so : 1.82 1.86 1.53 6/150 3658 T: 0 ( 3621) P:90 I:1000 C:1596828 Min: 20 Act: 25 Avg: 93 Max: 512 T: 1 ( 3622) P:89 I:1500 C:1064525 Min: 53 Act: 95 Avg: 94 Max: 15586 I have captured a latency trace for the above run (using cyclictest -b as shown above), but I'm not sure it makes much sense. It weights almost 4 MB, so I'll not put in inline, get it from: http://www.popies.net/tmp/latency-trace-1 Any idea ? Thanks, -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le dimanche 07 janvier 2007 à 09:44 -0200, Mauro Carvalho Chehab a écrit : > > > We can, however use this approach as a workaround, with > > > the proper documentation. I'll handle it after I return from vacations > > > next week. > Ok, I've wrote such patch. I should send today or tomorrow to Linus, > together with other patches. Hi Mauro, The __ucmpdi2() problem is still present in 2.6.20-rc5, please (re)send your patch to Linus before 2.6.20 goes final... Thanks. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le dimanche 07 janvier 2007 à 09:44 -0200, Mauro Carvalho Chehab a écrit : We can, however use this approach as a workaround, with the proper documentation. I'll handle it after I return from vacations next week. Ok, I've wrote such patch. I should send today or tomorrow to Linus, together with other patches. Hi Mauro, The __ucmpdi2() problem is still present in 2.6.20-rc5, please (re)send your patch to Linus before 2.6.20 goes final... Thanks. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypi not for 64bit?
Le dimanche 07 janvier 2007 à 03:21 +0100, Jan Engelhardt a écrit : > Hi sonypi (ex-)maintainers ;-) > > > drivers/char/Kconfig lists SONYPI as being !64BIT, however, there seem > to be sony users with x86_64 [1] around. Indeed, I have had (private) reports about it working on x86_64 too. > Is it just caution (it's also > marked EXPERIMENTAL) or is it definitely known to break on 64bit? Frankly I don't recall anymore. The 64 bit restriction wasn't there from the beginning, it was added by a patch from someone 2 or 3 years ago. git doesn't seem to have the history for that, maybe old bk does... -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypi not for 64bit?
Le dimanche 07 janvier 2007 à 03:21 +0100, Jan Engelhardt a écrit : Hi sonypi (ex-)maintainers ;-) drivers/char/Kconfig lists SONYPI as being !64BIT, however, there seem to be sony users with x86_64 [1] around. Indeed, I have had (private) reports about it working on x86_64 too. Is it just caution (it's also marked EXPERIMENTAL) or is it definitely known to break on 64bit? Frankly I don't recall anymore. The 64 bit restriction wasn't there from the beginning, it was added by a patch from someone 2 or 3 years ago. git doesn't seem to have the history for that, maybe old bk does... -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit : > > > What needs to happen is > > > 1. a maintainer for sony_acpi.c needs to step forward > > > I can't do this, I'm not allowed to be in the reverse engineering > > > business. > > > > Well, I can't do this either, because I just don't have the required > > hardware anymore. > > > > If someone want to step forward now it is a great time ! > > I have the hw and I'd be happy to do some basic working on the code FYI, sonypi is also searching for a new maintainer, and it is quite closely related to sony_acpi... If you are interested by the job, it is all yours. :) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le vendredi 05 janvier 2007 à 01:11 +0100, Jan Engelhardt a écrit : > On Jan 5 2007 00:36, Stelian Pop wrote: > >@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv > > > > static acpi_handle sony_acpi_handle; > > static struct proc_dir_entry *sony_acpi_dir; > >+static struct acpi_device *sony_acpi_acpi_device = NULL; > > acpi_acpi? Yeah, maybe Mattia will have more imagination than I at naming variables :) -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:16 -0800, Andrew Morton a écrit : > On Fri, 05 Jan 2007 00:54:32 +0100 > Stelian Pop <[EMAIL PROTECTED]> wrote: > > > Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit : > > > On Fri, 05 Jan 2007 00:36:23 +0100 > > > Stelian Pop <[EMAIL PROTECTED]> wrote: > > > > > > > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi > > > > subsystem, > > > > and made correspondent necessary changes for this to work. > > > > > > neato. > > > > > > err, how does one use this? > > > > :) > > > > Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not > > only this one), the Fn key events aren't seen by sonypi or sony_acpi > > GHKE method, but do generate an ACPI notify event. > > Speak English ;) Oh, sorry, I'll try again :) There are several ways of detecting the Fn key events, depending on the Vaio series: - some Vaios report them using the SPIC device (driven by sonypi) - some Vaios let the driver poll for the Fn key status using the GHKE ACPI method of the SNC device (driven by sony_acpi) - some Vaios generate an ACPI notify event on the SNC device when a Fn key is pressed - this is what the latest patch is for. Unfortunately there are way too many different Vaio series, and no information about what series support what method. I should have maintained some sort of wiki to let the users build themselves a comprehensive list, but I never get around to do it. Maybe Mattia could do it if he has the time and will... > > For those laptops, the patch forwards the ACPI event to the ACPI system > > and can be later interpreted in userspace using > > acpid's /etc/acpi/default.sh (example directly from Nilton): > > The only things Mr Red Hat gave me are /etc/acpi/events/sample.conf and > /etc/acpi/events/video.conf. Well, there was an /etc/acpi/default.sh in an older version of acpid... I'm not sure what it looks like now on a recent Fedora but on my Ubuntu I still have an acpid package, which has some files in /etc/acpi/ looking familiar. > I pressed then released a button and dmesg said > > [ 76.961568] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 1 > [ 76.961576] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 > [ 76.963277] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 0 > [ 76.963284] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 > [ 76.967341] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 1 > [ 76.967349] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 > [ 76.968136] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 0 > [ 76.968143] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 > > Nothing else happened. Well, you got the events from evdev, which means you probably got them directly from sonypi (or the regular keyboard..) Unless your distribution does some neat tricks and somehow feeds the events coming from somewhere into the event subsystem (like Ubuntu's acpi_fakekey for example...). Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:16 -0800, Andrew Morton a écrit : On Fri, 05 Jan 2007 00:54:32 +0100 Stelian Pop [EMAIL PROTECTED] wrote: Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit : On Fri, 05 Jan 2007 00:36:23 +0100 Stelian Pop [EMAIL PROTECTED] wrote: Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem, and made correspondent necessary changes for this to work. neato. err, how does one use this? :) Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not only this one), the Fn key events aren't seen by sonypi or sony_acpi GHKE method, but do generate an ACPI notify event. Speak English ;) Oh, sorry, I'll try again :) There are several ways of detecting the Fn key events, depending on the Vaio series: - some Vaios report them using the SPIC device (driven by sonypi) - some Vaios let the driver poll for the Fn key status using the GHKE ACPI method of the SNC device (driven by sony_acpi) - some Vaios generate an ACPI notify event on the SNC device when a Fn key is pressed - this is what the latest patch is for. Unfortunately there are way too many different Vaio series, and no information about what series support what method. I should have maintained some sort of wiki to let the users build themselves a comprehensive list, but I never get around to do it. Maybe Mattia could do it if he has the time and will... For those laptops, the patch forwards the ACPI event to the ACPI system and can be later interpreted in userspace using acpid's /etc/acpi/default.sh (example directly from Nilton): The only things Mr Red Hat gave me are /etc/acpi/events/sample.conf and /etc/acpi/events/video.conf. Well, there was an /etc/acpi/default.sh in an older version of acpid... I'm not sure what it looks like now on a recent Fedora but on my Ubuntu I still have an acpid package, which has some files in /etc/acpi/ looking familiar. I pressed then released a button and dmesg said [ 76.961568] evbug.c: Event. Dev: NULL, Type: 1, Code: 148, Value: 1 [ 76.961576] evbug.c: Event. Dev: NULL, Type: 0, Code: 0, Value: 0 [ 76.963277] evbug.c: Event. Dev: NULL, Type: 1, Code: 148, Value: 0 [ 76.963284] evbug.c: Event. Dev: NULL, Type: 0, Code: 0, Value: 0 [ 76.967341] evbug.c: Event. Dev: NULL, Type: 1, Code: 148, Value: 1 [ 76.967349] evbug.c: Event. Dev: NULL, Type: 0, Code: 0, Value: 0 [ 76.968136] evbug.c: Event. Dev: NULL, Type: 1, Code: 148, Value: 0 [ 76.968143] evbug.c: Event. Dev: NULL, Type: 0, Code: 0, Value: 0 Nothing else happened. Well, you got the events from evdev, which means you probably got them directly from sonypi (or the regular keyboard..) Unless your distribution does some neat tricks and somehow feeds the events coming from somewhere into the event subsystem (like Ubuntu's acpi_fakekey for example...). Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le vendredi 05 janvier 2007 à 01:11 +0100, Jan Engelhardt a écrit : On Jan 5 2007 00:36, Stelian Pop wrote: @@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv static acpi_handle sony_acpi_handle; static struct proc_dir_entry *sony_acpi_dir; +static struct acpi_device *sony_acpi_acpi_device = NULL; acpi_acpi? Yeah, maybe Mattia will have more imagination than I at naming variables :) -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit : What needs to happen is 1. a maintainer for sony_acpi.c needs to step forward I can't do this, I'm not allowed to be in the reverse engineering business. Well, I can't do this either, because I just don't have the required hardware anymore. If someone want to step forward now it is a great time ! I have the hw and I'd be happy to do some basic working on the code FYI, sonypi is also searching for a new maintainer, and it is quite closely related to sony_acpi... If you are interested by the job, it is all yours. :) Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit : > On Fri, 05 Jan 2007 00:36:23 +0100 > Stelian Pop <[EMAIL PROTECTED]> wrote: > > > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi > > subsystem, > > and made correspondent necessary changes for this to work. > > neato. > > err, how does one use this? :) Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not only this one), the Fn key events aren't seen by sonypi or sony_acpi GHKE method, but do generate an ACPI notify event. For those laptops, the patch forwards the ACPI event to the ACPI system and can be later interpreted in userspace using acpid's /etc/acpi/default.sh (example directly from Nilton): > case "$group" in > button) > case "$action" in > power) /usr/sbin/hibernate > ;; > > lid) cat /proc/acpi/button/lid/LID/state > ;; > > *) logger "ACPI action $action is not defined ($@)" > ;; > esac > ;; > > SNC) echo "$@" > /dev/tcp/localhost/50007 > ;; > > *) logger "ACPI group $group / action $action is not defined" > ;; > esac > > In which I just forward the SNC event to another userspace application > listening on a TCP port. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
pi_remove(struct acpi_
acpi_status status;
struct sony_acpi_value *item;
- if (debug) {
- status = acpi_remove_notify_handler(sony_acpi_handle,
- ACPI_DEVICE_NOTIFY,
- sony_acpi_notify);
- if (ACPI_FAILURE(status))
- printk(LOG_PFX "unable to remove notify handler\n");
- }
+ sony_acpi_acpi_device = NULL;
+
+ status = acpi_remove_notify_handler(sony_acpi_handle,
+ ACPI_DEVICE_NOTIFY,
+ sony_acpi_notify);
+ if (ACPI_FAILURE(status))
+ printk(LOG_PFX "unable to remove notify handler\n");
for (item = sony_acpi_values; item->name; ++item)
if (item->proc)
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit : > > If someone want to step forward now it is a great time ! > > I have the hw and I'd be happy to do some basic working on the code Cool ! > but: > - I'll probably need some help; Feel free to ask... > - I'll have an almost-blackout between the end of February and the end > of April as I'm moving to a different country and I'll need some time > before I can be active again (I hope I'll have at least easy mail > access for all the time though). Well, I am the current "maintainer" for this and it has probably been a year since I left Sony's laptop world, so I guess it won't make much difference if you're not very active for a month or two :) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le jeudi 04 janvier 2007 à 20:59 -0200, Mauro Carvalho Chehab a écrit : > > The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't > > be 64-bit? > Too late to change it to 32 bits. It is at V4L2 userspace API since > kernel 2.6.0. We can, however use this approach as a workaround, with > the proper documentation. Maybe with a BUG_ON(id > UINT_MAX) ? Linus, do you want a patch for this or will you take the _ucmppdi2 ppc patch as per http://lkml.org/lkml/2006/12/17/46 instead ? Thanks, Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le jeudi 04 janvier 2007 à 04:09 -0800, Trent Piepho a écrit : > On Thu, 4 Jan 2007, Stelian Pop wrote: > > This patch replaces a switch statement using 64 bit values with the > > if/else equivalent in order to prevent a call __ucmpdi2 generated by > > some versions of gcc (verified with gcc-4.1.2 20060928): > > > > drivers/built-in.o: In function `v4l2_norm_to_name': > > (.text+0x71100): undefined reference to `__ucmpdi2' > > > > Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> > > It looks like there is a much better way to handle this problem here: > http://lkml.org/lkml/2006/12/17/46 > > Basically: > A. Fix gcc so it doesn't call in __ucmpdi2 (already fixed?) > B. Link in __ucmpdi2 from libgcc > C. Write arch specific code to provide __ucmpdi2 Indeed, I didn't see that thread. Linus, just make sure you apply a fix for this problem before 2.4.20 goes final... Thanks and sorry for the noise. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Hi,
This patch replaces a switch statement using 64 bit values with the
if/else equivalent in order to prevent a call __ucmpdi2 generated by
some versions of gcc (verified with gcc-4.1.2 20060928):
drivers/built-in.o: In function `v4l2_norm_to_name':
(.text+0x71100): undefined reference to `__ucmpdi2'
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
---
drivers/media/video/v4l2-common.c | 126 ++---
1 files changed, 62 insertions(+), 64 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 752c82c..0c3c2f6 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -91,70 +91,68 @@ char *v4l2_norm_to_name(v4l2_std_id id)
{
char *name;
- switch (id) {
- case V4L2_STD_PAL:
- name="PAL"; break;
- case V4L2_STD_PAL_BG:
- name="PAL-BG"; break;
- case V4L2_STD_PAL_DK:
- name="PAL-DK"; break;
- case V4L2_STD_PAL_B:
- name="PAL-B"; break;
- case V4L2_STD_PAL_B1:
- name="PAL-B1"; break;
- case V4L2_STD_PAL_G:
- name="PAL-G"; break;
- case V4L2_STD_PAL_H:
- name="PAL-H"; break;
- case V4L2_STD_PAL_I:
- name="PAL-I"; break;
- case V4L2_STD_PAL_D:
- name="PAL-D"; break;
- case V4L2_STD_PAL_D1:
- name="PAL-D1"; break;
- case V4L2_STD_PAL_K:
- name="PAL-K"; break;
- case V4L2_STD_PAL_M:
- name="PAL-M"; break;
- case V4L2_STD_PAL_N:
- name="PAL-N"; break;
- case V4L2_STD_PAL_Nc:
- name="PAL-Nc"; break;
- case V4L2_STD_PAL_60:
- name="PAL-60"; break;
- case V4L2_STD_NTSC:
- name="NTSC";break;
- case V4L2_STD_NTSC_M:
- name="NTSC-M"; break;
- case V4L2_STD_NTSC_M_JP:
- name="NTSC-M-JP"; break;
- case V4L2_STD_NTSC_443:
- name="NTSC-443";break;
- case V4L2_STD_NTSC_M_KR:
- name="NTSC-M-KR"; break;
- case V4L2_STD_SECAM:
- name="SECAM"; break;
- case V4L2_STD_SECAM_DK:
- name="SECAM-DK";break;
- case V4L2_STD_SECAM_B:
- name="SECAM-B"; break;
- case V4L2_STD_SECAM_D:
- name="SECAM-D"; break;
- case V4L2_STD_SECAM_G:
- name="SECAM-G"; break;
- case V4L2_STD_SECAM_H:
- name="SECAM-H"; break;
- case V4L2_STD_SECAM_K:
- name="SECAM-K"; break;
- case V4L2_STD_SECAM_K1:
- name="SECAM-K1";break;
- case V4L2_STD_SECAM_L:
- name="SECAM-L"; break;
- case V4L2_STD_SECAM_LC:
- name="SECAM-LC";break;
- default:
- name="Unknown"; break;
- }
+ if (id == V4L2_STD_PAL)
+ name = "PAL";
+ else if (id == V4L2_STD_PAL_BG)
+ name = "PAL-BG";
+ else if (id == V4L2_STD_PAL_DK)
+ name = "PAL-DK";
+ else if (id == V4L2_STD_PAL_B)
+ name = "PAL-B";
+ else if (id == V4L2_STD_PAL_B1)
+ name = "PAL-B1";
+ else if (id == V4L2_STD_PAL_G)
+ name = "PAL-G";
+ else if (id == V4L2_STD_PAL_H)
+ name = "PAL-H";
+ else if (id == V4L2_STD_PAL_I)
+ name = "PAL-I";
+ else if (id == V4L2_STD_PAL_D)
+ name = "PAL-D";
+ else if (id == V4L2_STD_PAL_D1)
+ name = "PAL-D1";
+ else if (id == V4L2_STD_PAL_K)
+ name = "PAL-K";
+ else if (id == V4L2_STD_PAL_M)
+ name = "PAL-M";
+ else if (id == V4L2_STD_PAL_N)
+ name = "PAL-N";
+ else if (id == V4L2_STD_PAL_Nc)
+ name = "PAL-Nc";
+ else if (id == V4L2_STD_PAL_60)
+ name = "PAL-60";
+ else if (id == V4L2_STD_NTSC)
+ name = "NTSC";
+ else if (id == V4L2_STD_NTSC_M)
+ name = "NTSC-M";
+ else if (id == V4L2_STD_NTSC_M_JP)
+ name = "NTSC-M-JP"
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 00:24 -0500, Len Brown a écrit : > > > I'd like to keep this driver out-of-tree > > > until we prove that we can't enhance the > > > generic code to handle this hardware > > > without the addition of a new driver. > > > > How long is this going to take ? > > How about 2.6.21? Good news ! > What needs to happen is > 1. a maintainer for sony_acpi.c needs to step forward > I can't do this, I'm not allowed to be in the reverse engineering > business. Well, I can't do this either, because I just don't have the required hardware anymore. If someone want to step forward now it is a great time ! > > 2. /proc/acpi/sony API needs to be deleted > > 3. source needs to move out of drivers/acpi, and into drivers/misc along with > msi. Sensible suggestions, the new maintainer will have to work on this. Thanks Len. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Hi,
This patch replaces a switch statement using 64 bit values with the
if/else equivalent in order to prevent a call __ucmpdi2 generated by
some versions of gcc (verified with gcc-4.1.2 20060928):
drivers/built-in.o: In function `v4l2_norm_to_name':
(.text+0x71100): undefined reference to `__ucmpdi2'
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
---
drivers/media/video/v4l2-common.c | 126 ++---
1 files changed, 62 insertions(+), 64 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 752c82c..0c3c2f6 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -91,70 +91,68 @@ char *v4l2_norm_to_name(v4l2_std_id id)
{
char *name;
- switch (id) {
- case V4L2_STD_PAL:
- name=PAL; break;
- case V4L2_STD_PAL_BG:
- name=PAL-BG; break;
- case V4L2_STD_PAL_DK:
- name=PAL-DK; break;
- case V4L2_STD_PAL_B:
- name=PAL-B; break;
- case V4L2_STD_PAL_B1:
- name=PAL-B1; break;
- case V4L2_STD_PAL_G:
- name=PAL-G; break;
- case V4L2_STD_PAL_H:
- name=PAL-H; break;
- case V4L2_STD_PAL_I:
- name=PAL-I; break;
- case V4L2_STD_PAL_D:
- name=PAL-D; break;
- case V4L2_STD_PAL_D1:
- name=PAL-D1; break;
- case V4L2_STD_PAL_K:
- name=PAL-K; break;
- case V4L2_STD_PAL_M:
- name=PAL-M; break;
- case V4L2_STD_PAL_N:
- name=PAL-N; break;
- case V4L2_STD_PAL_Nc:
- name=PAL-Nc; break;
- case V4L2_STD_PAL_60:
- name=PAL-60; break;
- case V4L2_STD_NTSC:
- name=NTSC;break;
- case V4L2_STD_NTSC_M:
- name=NTSC-M; break;
- case V4L2_STD_NTSC_M_JP:
- name=NTSC-M-JP; break;
- case V4L2_STD_NTSC_443:
- name=NTSC-443;break;
- case V4L2_STD_NTSC_M_KR:
- name=NTSC-M-KR; break;
- case V4L2_STD_SECAM:
- name=SECAM; break;
- case V4L2_STD_SECAM_DK:
- name=SECAM-DK;break;
- case V4L2_STD_SECAM_B:
- name=SECAM-B; break;
- case V4L2_STD_SECAM_D:
- name=SECAM-D; break;
- case V4L2_STD_SECAM_G:
- name=SECAM-G; break;
- case V4L2_STD_SECAM_H:
- name=SECAM-H; break;
- case V4L2_STD_SECAM_K:
- name=SECAM-K; break;
- case V4L2_STD_SECAM_K1:
- name=SECAM-K1;break;
- case V4L2_STD_SECAM_L:
- name=SECAM-L; break;
- case V4L2_STD_SECAM_LC:
- name=SECAM-LC;break;
- default:
- name=Unknown; break;
- }
+ if (id == V4L2_STD_PAL)
+ name = PAL;
+ else if (id == V4L2_STD_PAL_BG)
+ name = PAL-BG;
+ else if (id == V4L2_STD_PAL_DK)
+ name = PAL-DK;
+ else if (id == V4L2_STD_PAL_B)
+ name = PAL-B;
+ else if (id == V4L2_STD_PAL_B1)
+ name = PAL-B1;
+ else if (id == V4L2_STD_PAL_G)
+ name = PAL-G;
+ else if (id == V4L2_STD_PAL_H)
+ name = PAL-H;
+ else if (id == V4L2_STD_PAL_I)
+ name = PAL-I;
+ else if (id == V4L2_STD_PAL_D)
+ name = PAL-D;
+ else if (id == V4L2_STD_PAL_D1)
+ name = PAL-D1;
+ else if (id == V4L2_STD_PAL_K)
+ name = PAL-K;
+ else if (id == V4L2_STD_PAL_M)
+ name = PAL-M;
+ else if (id == V4L2_STD_PAL_N)
+ name = PAL-N;
+ else if (id == V4L2_STD_PAL_Nc)
+ name = PAL-Nc;
+ else if (id == V4L2_STD_PAL_60)
+ name = PAL-60;
+ else if (id == V4L2_STD_NTSC)
+ name = NTSC;
+ else if (id == V4L2_STD_NTSC_M)
+ name = NTSC-M;
+ else if (id == V4L2_STD_NTSC_M_JP)
+ name = NTSC-M-JP;
+ else if (id == V4L2_STD_NTSC_443)
+ name = NTSC-443;
+ else if (id == V4L2_STD_NTSC_M_KR)
+ name = NTSC-M-KR;
+ else if (id == V4L2_STD_SECAM)
+ name = SECAM;
+ else if (id == V4L2_STD_SECAM_DK)
+ name = SECAM-DK;
+ else if (id == V4L2_STD_SECAM_B)
+ name = SECAM-B;
+ else if (id == V4L2_STD_SECAM_D)
+ name = SECAM-D;
+ else if (id == V4L2_STD_SECAM_G)
+ name = SECAM-G;
+ else if (id == V4L2_STD_SECAM_H)
+ name = SECAM-H;
+ else if (id
Re: [v4l-dvb-maintainer] [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le jeudi 04 janvier 2007 à 04:09 -0800, Trent Piepho a écrit : On Thu, 4 Jan 2007, Stelian Pop wrote: This patch replaces a switch statement using 64 bit values with the if/else equivalent in order to prevent a call __ucmpdi2 generated by some versions of gcc (verified with gcc-4.1.2 20060928): drivers/built-in.o: In function `v4l2_norm_to_name': (.text+0x71100): undefined reference to `__ucmpdi2' Signed-off-by: Stelian Pop [EMAIL PROTECTED] It looks like there is a much better way to handle this problem here: http://lkml.org/lkml/2006/12/17/46 Basically: A. Fix gcc so it doesn't call in __ucmpdi2 (already fixed?) B. Link in __ucmpdi2 from libgcc C. Write arch specific code to provide __ucmpdi2 Indeed, I didn't see that thread. Linus, just make sure you apply a fix for this problem before 2.4.20 goes final... Thanks and sorry for the noise. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 00:24 -0500, Len Brown a écrit : I'd like to keep this driver out-of-tree until we prove that we can't enhance the generic code to handle this hardware without the addition of a new driver. How long is this going to take ? How about 2.6.21? Good news ! What needs to happen is 1. a maintainer for sony_acpi.c needs to step forward I can't do this, I'm not allowed to be in the reverse engineering business. Well, I can't do this either, because I just don't have the required hardware anymore. If someone want to step forward now it is a great time ! 2. /proc/acpi/sony API needs to be deleted 3. source needs to move out of drivers/acpi, and into drivers/misc along with msi. Sensible suggestions, the new maintainer will have to work on this. Thanks Len. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le jeudi 04 janvier 2007 à 20:59 -0200, Mauro Carvalho Chehab a écrit : The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't be 64-bit? Too late to change it to 32 bits. It is at V4L2 userspace API since kernel 2.6.0. We can, however use this approach as a workaround, with the proper documentation. Maybe with a BUG_ON(id UINT_MAX) ? Linus, do you want a patch for this or will you take the _ucmppdi2 ppc patch as per http://lkml.org/lkml/2006/12/17/46 instead ? Thanks, Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit : If someone want to step forward now it is a great time ! I have the hw and I'd be happy to do some basic working on the code Cool ! but: - I'll probably need some help; Feel free to ask... - I'll have an almost-blackout between the end of February and the end of April as I'm moving to a different country and I'll need some time before I can be active again (I hope I'll have at least easy mail access for all the time though). Well, I am the current maintainer for this and it has probably been a year since I left Sony's laptop world, so I guess it won't make much difference if you're not very active for a month or two :) Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
, - sony_acpi_notify); - if (ACPI_FAILURE(status)) - printk(LOG_PFX unable to remove notify handler\n); - } + sony_acpi_acpi_device = NULL; + + status = acpi_remove_notify_handler(sony_acpi_handle, + ACPI_DEVICE_NOTIFY, + sony_acpi_notify); + if (ACPI_FAILURE(status)) + printk(LOG_PFX unable to remove notify handler\n); for (item = sony_acpi_values; item-name; ++item) if (item-proc) -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit : On Fri, 05 Jan 2007 00:36:23 +0100 Stelian Pop [EMAIL PROTECTED] wrote: Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem, and made correspondent necessary changes for this to work. neato. err, how does one use this? :) Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not only this one), the Fn key events aren't seen by sonypi or sony_acpi GHKE method, but do generate an ACPI notify event. For those laptops, the patch forwards the ACPI event to the ACPI system and can be later interpreted in userspace using acpid's /etc/acpi/default.sh (example directly from Nilton): case $group in button) case $action in power) /usr/sbin/hibernate ;; lid) cat /proc/acpi/button/lid/LID/state ;; *) logger ACPI action $action is not defined ($@) ;; esac ;; SNC) echo $@ /dev/tcp/localhost/50007 ;; *) logger ACPI group $group / action $action is not defined ;; esac In which I just forward the SNC event to another userspace application listening on a TCP port. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-git2 crashes on iBook
Le jeudi 01 septembre 2005 à 20:26 +0100, Daniel Drake a écrit : > Hi, > > Stelian Pop wrote: > > Confirmed on an Apple Powerbook too. > > > > For reference, the (already reverted) patch which needs to be applied is > > below. > > > > Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> > > > > Index: linux-2.6.git/drivers/pci/setup-res.c [...] > Sorry for my ignorance. Which tree was this reverted in? You are probably > aware that this bug made it into 2.6.13 (patch was not reverted there). It must be my bad english but I wasn't implying that the patch was reverted in 2.6.13 but that one should apply it (just apply, without -R, because I didn't attach the original patch but a reversed version of it) on a clean 2.6.13 tree in order to make it work. :) However, a different fix (a real fix, not the workaround proposed above) was discussed on lkml this week and BenH proposed a patch I haven't had the chance to test yet (see http://lkml.org/lkml/2005/8/31/1 ). Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-git2 crashes on iBook
Le jeudi 01 septembre 2005 à 20:26 +0100, Daniel Drake a écrit : Hi, Stelian Pop wrote: Confirmed on an Apple Powerbook too. For reference, the (already reverted) patch which needs to be applied is below. Signed-off-by: Stelian Pop [EMAIL PROTECTED] Index: linux-2.6.git/drivers/pci/setup-res.c [...] Sorry for my ignorance. Which tree was this reverted in? You are probably aware that this bug made it into 2.6.13 (patch was not reverted there). It must be my bad english but I wasn't implying that the patch was reverted in 2.6.13 but that one should apply it (just apply, without -R, because I didn't attach the original patch but a reversed version of it) on a clean 2.6.13 tree in order to make it work. :) However, a different fix (a real fix, not the workaround proposed above) was discussed on lkml this week and BenH proposed a patch I haven't had the chance to test yet (see http://lkml.org/lkml/2005/8/31/1 ). Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-git2 crashes on iBook
Le dimanche 28 août 2005 à 22:02 -0600, Alex Williamson a écrit :
> On Sun, 2005-08-28 at 13:20 +0200, Andreas Schwab wrote:
> > The last change to drivers/pci/setup-res.c (Ignore disabled ROM resources
> > at setup) is breaking radeonfb on iBook G3 (with Radeon Mobility M6 LY).
> > It crashes in pci_map_rom when called from radeonfb_map_ROM. This is
> > probably a dormant bug that was just uncovered by the change.
>
>Same thing on Mac Mini. 2.6.13 doesn't boot. Revert the
> drivers/pci/setup-res.c change from rc7-git2 and it seems ok.
Confirmed on an Apple Powerbook too.
For reference, the (already reverted) patch which needs to be applied is
below.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
Index: linux-2.6.git/drivers/pci/setup-res.c
===
--- linux-2.6.git.orig/drivers/pci/setup-res.c 2005-08-29 10:03:00.0
+0200
+++ linux-2.6.git/drivers/pci/setup-res.c 2005-08-29 12:23:20.980716336
+0200
@@ -53,9 +53,7 @@
if (resno < 6) {
reg = PCI_BASE_ADDRESS_0 + 4 * resno;
} else if (resno == PCI_ROM_RESOURCE) {
- if (!(res->flags & IORESOURCE_ROM_ENABLE))
- return;
- new |= PCI_ROM_ADDRESS_ENABLE;
+ new |= res->flags & IORESOURCE_ROM_ENABLE;
reg = dev->rom_base_reg;
} else {
/* Hmm, non-standard resource. */
Stelian.
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-git2 crashes on iBook
Le dimanche 28 août 2005 à 22:02 -0600, Alex Williamson a écrit :
On Sun, 2005-08-28 at 13:20 +0200, Andreas Schwab wrote:
The last change to drivers/pci/setup-res.c (Ignore disabled ROM resources
at setup) is breaking radeonfb on iBook G3 (with Radeon Mobility M6 LY).
It crashes in pci_map_rom when called from radeonfb_map_ROM. This is
probably a dormant bug that was just uncovered by the change.
Same thing on Mac Mini. 2.6.13 doesn't boot. Revert the
drivers/pci/setup-res.c change from rc7-git2 and it seems ok.
Confirmed on an Apple Powerbook too.
For reference, the (already reverted) patch which needs to be applied is
below.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
Index: linux-2.6.git/drivers/pci/setup-res.c
===
--- linux-2.6.git.orig/drivers/pci/setup-res.c 2005-08-29 10:03:00.0
+0200
+++ linux-2.6.git/drivers/pci/setup-res.c 2005-08-29 12:23:20.980716336
+0200
@@ -53,9 +53,7 @@
if (resno 6) {
reg = PCI_BASE_ADDRESS_0 + 4 * resno;
} else if (resno == PCI_ROM_RESOURCE) {
- if (!(res-flags IORESOURCE_ROM_ENABLE))
- return;
- new |= PCI_ROM_ADDRESS_ENABLE;
+ new |= res-flags IORESOURCE_ROM_ENABLE;
reg = dev-rom_base_reg;
} else {
/* Hmm, non-standard resource. */
Stelian.
--
Stelian Pop [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Export handle_mm_fault to modules.
Le vendredi 05 août 2005 à 16:43 -0700, Linus Torvalds a écrit : > > On Fri, 5 Aug 2005, Olof Johansson wrote: > > > > On Fri, Aug 05, 2005 at 04:02:13PM -0700, Linus Torvalds wrote: > > > > > The only thing that has ever exported it afaik is > > > > > > arch/ppc/kernel/ppc_ksyms.c:EXPORT_SYMBOL(handle_mm_fault); /* For MOL > > > */ > > > > > > and that looks pretty suspicious too (what is MOL, and regardless, > > > shouldn't it be an EXPORT_SYMBOL_GPL?). > > > > Mac-on-Linux, see http://www.maconlinux.org/. Run MacOS in a virtualized > > machine under Linux (or the other way around). It's GPL. > > Ok. Then I suspect the right patch is this one. Stelian, can you verify? I confirm, it works perfectly. Stelian. > > Linus > --- > diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c > --- a/arch/ppc/kernel/ppc_ksyms.c > +++ b/arch/ppc/kernel/ppc_ksyms.c > @@ -324,7 +324,7 @@ EXPORT_SYMBOL(__res); > > EXPORT_SYMBOL(next_mmu_context); > EXPORT_SYMBOL(set_context); > -EXPORT_SYMBOL(handle_mm_fault); /* For MOL */ > +EXPORT_SYMBOL_GPL(__handle_mm_fault); /* For MOL */ > EXPORT_SYMBOL(disarm_decr); > #ifdef CONFIG_PPC_STD_MMU > extern long mol_trampoline; > -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Export handle_mm_fault to modules.
Le vendredi 05 août 2005 à 16:43 -0700, Linus Torvalds a écrit : On Fri, 5 Aug 2005, Olof Johansson wrote: On Fri, Aug 05, 2005 at 04:02:13PM -0700, Linus Torvalds wrote: The only thing that has ever exported it afaik is arch/ppc/kernel/ppc_ksyms.c:EXPORT_SYMBOL(handle_mm_fault); /* For MOL */ and that looks pretty suspicious too (what is MOL, and regardless, shouldn't it be an EXPORT_SYMBOL_GPL?). Mac-on-Linux, see http://www.maconlinux.org/. Run MacOS in a virtualized machine under Linux (or the other way around). It's GPL. Ok. Then I suspect the right patch is this one. Stelian, can you verify? I confirm, it works perfectly. Stelian. Linus --- diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c --- a/arch/ppc/kernel/ppc_ksyms.c +++ b/arch/ppc/kernel/ppc_ksyms.c @@ -324,7 +324,7 @@ EXPORT_SYMBOL(__res); EXPORT_SYMBOL(next_mmu_context); EXPORT_SYMBOL(set_context); -EXPORT_SYMBOL(handle_mm_fault); /* For MOL */ +EXPORT_SYMBOL_GPL(__handle_mm_fault); /* For MOL */ EXPORT_SYMBOL(disarm_decr); #ifdef CONFIG_PPC_STD_MMU extern long mol_trampoline; -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Export handle_mm_fault to modules.
handle_mm_fault changed from an inline function to a non-inline one (__handle_mm_fault), which is not available to external kernel modules. The patch below fixes this. Stelian. Export __handle_mm_fault to modules (called by the inlined handle_mm_fault function). Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Index: linux-2.6.git/mm/memory.c === --- linux-2.6.git.orig/mm/memory.c 2005-08-05 22:26:20.0 +0200 +++ linux-2.6.git/mm/memory.c 2005-08-05 23:46:49.0 +0200 @@ -2061,6 +2061,7 @@ spin_unlock(>page_table_lock); return VM_FAULT_OOM; } +EXPORT_SYMBOL(__handle_mm_fault); #ifndef __PAGETABLE_PUD_FOLDED /* -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Export handle_mm_fault to modules.
handle_mm_fault changed from an inline function to a non-inline one (__handle_mm_fault), which is not available to external kernel modules. The patch below fixes this. Stelian. Export __handle_mm_fault to modules (called by the inlined handle_mm_fault function). Signed-off-by: Stelian Pop [EMAIL PROTECTED] Index: linux-2.6.git/mm/memory.c === --- linux-2.6.git.orig/mm/memory.c 2005-08-05 22:26:20.0 +0200 +++ linux-2.6.git/mm/memory.c 2005-08-05 23:46:49.0 +0200 @@ -2061,6 +2061,7 @@ spin_unlock(mm-page_table_lock); return VM_FAULT_OOM; } +EXPORT_SYMBOL(__handle_mm_fault); #ifndef __PAGETABLE_PUD_FOLDED /* -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerbook power-off and 2.6.13-rc[3,4]
Le mardi 02 août 2005 à 14:54 +0200, Pavel Machek a écrit : > Hi! > > > > > Pavel Machek wrote: > > > > > > > > >Can you try without USB? > > > > > > > > > Not really. The keyboard is USB, and there's no PS/2 connector. I guess > > > > I maybe could do it via a timer, unload the modules and then have it > > > > shut down afterwards... > > > > > > I'll build a kernel without USB and drive the laptop over the net and > > > see what happens. > > > > Without CONFIG_USB the poweroff still hangs, and this time the panel > > goes completly white with dark spots appearing all over it (kinda scary > > btw). A 5 seconds press on the power button force it to power off. > > Yep, looks like screen burning, right? Exactly. > So it is different kind of hang > => USB has some problem but there's another one, too? Seems that this is the case, yes. > > This is on a 2.6.13-rc4, and I'm attaching the .config in case it > > matters. > > Could you try inserting printks to see where it hangs? Aha, with > display turned off that is not going to be funny. Unfortunately I won't have time to debug this right now (I leave on vacation tomorrow), so somebody else will have to do it (and no, it is not going to be funny to do this without display, serial port, buzzer etc) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerbook power-off and 2.6.13-rc[3,4]
Le mardi 02 août 2005 à 13:43 +0200, Stelian Pop a écrit : > > Pavel Machek wrote: > > > > >Can you try without USB? > > > > > Not really. The keyboard is USB, and there's no PS/2 connector. I guess > > I maybe could do it via a timer, unload the modules and then have it > > shut down afterwards... > > I'll build a kernel without USB and drive the laptop over the net and > see what happens. Without CONFIG_USB the poweroff still hangs, and this time the panel goes completly white with dark spots appearing all over it (kinda scary btw). A 5 seconds press on the power button force it to power off. This is on a 2.6.13-rc4, and I'm attaching the .config in case it matters. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_TAU=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_PMAC=y CONFIG_PM=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_PREP=y CONFIG_PPC_OF=y CONFIG_PPCBUG_NVRAM=y CONFIG_HIGHMEM=y CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_PREEMPT_NONE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_PREP_RESIDUAL=y CONFIG_PROC_PREPRESIDUAL=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="console=ttyS0,9600 console=tty0 root=/dev/sda2" CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y CONFIG_YENTA=y CONFIG_PCCARD_NONSTATIC=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIB_HASH=y CONFIG_TCP_CONG_BIC=y CONFIG_NETFILTER=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_MATCH_ADDRTYPE=y CONFIG_IP_NF_MATCH_REALM=y CONFIG_IP_NF_MATCH_SCTP=y CONFIG_IP_NF_MATCH_COMMENT=y CONFIG_IP_NF_MATCH_HASHLIMIT=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_NET_CLS_ROUTE=y CONFIG_BT=y CONFIG_BT_L2CAP=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_HIDP=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_BLK_DEV_IDEDMA_PMAC=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_FC_ATTRS
Re: powerbook power-off and 2.6.13-rc[3,4]
Le mardi 02 août 2005 à 13:38 +0200, Johannes Berg a écrit : > Pavel Machek wrote: > > >Can you try without USB? > > > Not really. The keyboard is USB, and there's no PS/2 connector. I guess > I maybe could do it via a timer, unload the modules and then have it > shut down afterwards... I'll build a kernel without USB and drive the laptop over the net and see what happens. > > With USB but without experimental > >CONFIG_USB_SUSPEND? > > > > > I don't have USB_SUSPEND enabled, IIRC (don't have the PB with me, but > I'm pretty sure I checked this yesterday. If you don't hear back, assume > it wasn't enabled) I don't have USB_SUSPEND enabled. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] meye: use dma-mapping constants
Hi, This patch comes from the janitors and have been in my tree for quite some time now. Please apply. Stelian. Use the DMA_32BIT_MASK constant from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() This patch includes dma-mapping.h explicitly because it caused errors on some architectures otherwise. See http://marc.theaimsgroup.com/?t=10800199301=1=2 for details Signed-off-by: Tobias Klauser <[EMAIL PROTECTED]> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Index: linux-2.6.git/drivers/media/video/meye.c === --- linux-2.6.git.orig/drivers/media/video/meye.c 2005-07-08 14:08:17.0 +0200 +++ linux-2.6.git/drivers/media/video/meye.c2005-08-02 10:22:23.0 +0200 @@ -37,6 +37,7 @@ #include #include #include +#include #include "meye.h" #include @@ -121,7 +122,7 @@ memset(meye.mchip_ptable, 0, sizeof(meye.mchip_ptable)); /* give only 32 bit DMA addresses */ - if (dma_set_mask(_dev->dev, 0x)) + if (dma_set_mask(_dev->dev, DMA_32BIT_MASK)) return -1; meye.mchip_ptable_toc = dma_alloc_coherent(_dev->dev, -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sonypi: remove obsolete event
I had this one in my tree for a long time, please apply.
Stelian.
Remove old obsolete event.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-02 10:22:15.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:22:18.0 +0200
@@ -406,7 +406,6 @@
{ SONYPI_DEVICE_MODEL_TYPE2, 0x31, SONYPI_BLUETOOTH_MASK, sonypi_blueev
},
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_PKEY_MASK, sonypi_pkeyev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x11, SONYPI_BACK_MASK, sonypi_backev },
- { SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_HELP_MASK, sonypi_helpev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x21, SONYPI_HELP_MASK, sonypi_helpev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x21, SONYPI_ZOOM_MASK, sonypi_zoomev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x20, SONYPI_THUMBPHRASE_MASK,
sonypi_thumbphraseev },
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Le lundi 01 août 2005 à 16:37 +0200, Stelian Pop a écrit :
> > Also, it looks like sonypi really is pretty nasty to probe for, so it's
> > not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> > Otherwise I'd just suggest adding a "dmi_check_system()" table to
> > arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> > then you could just allocate things based on DMI information.
> Since every Vaio laptop out there seems indeed to use only the first IO
> port range in the list, we can de-nastyify the probe. And if we don't
> even bother to check for Type1 vs. Type2 devices and we reserve both,
> then it may be acceptable to do the above.
>
> See the attached patch below which does just that. This has NOT been
> tested (only compile-tested), and moreover it has a high breakage
> probability in case some Vaios cannot live with the fixed ioport choice.
>
> Note that this patch will conflict with the recent Eric's one (added in
> CC:), he may want to rediff his Type3 changes in case this patch gets
> in.
I had no feedback at all on the patch so I have no idea if this will go
in or not, but since Eric's patch was accepted into -mm I rediffed the
patch in order to ease the testing (in case someone is willing to test
it).
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
arch/i386/pci/i386.c | 42 +
drivers/char/sonypi.c | 71 ++
2 files changed, 57 insertions(+), 56 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-08-02 10:21:58.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-02 10:28:26.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "pci.h"
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, "Sony Programable I/O Type1 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type1 IO region\n");
+
+ /* IO ports for 'type2' and 'type3' devices */
+ if (!request_region(0x1080, 0x20, "Sony Programable I/O Type2 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type2 IO region\n");
+
+ printk(KERN_INFO "Sony Vaio: pre-reserved IO ports\n");
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PCG-"),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-"),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev->class >> 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-02 10:22:18.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:27:28.0 +0200
@@ -105,7 +105,9 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_TYPE1_BASE 0x50
#define SONYPI_G10A(SONYPI_TYPE1_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
@@ -113,13 +115,18 @@
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOP
Re: Fn key and 2.6.12-rc4
Le mardi 02 août 2005 à 09:17 +0200, Elimar Riesebieter a écrit :
> > [ fnkey not working on Apple Powerbooks in -mm tree ]
> > Hmm, there seem to be a lot of divergence between -mm and linus tree
> > here, and this may be the cause of the malfunction.
> >
> > Let me do some tests tomorrow with an -mm kernel and see if I find
> > something.
Ok, the -mm tree contains some other input patches which conflict with
my Fn key patch
(input-quirk-for-the-fn-key-on-powerbooks-with-an-usb.patch). The
attached patch makes it work again.
Andrew, please apply.
Stelian.
Newer input patches added a HID_UP_LOGIVENDOR switch case which disrupts
the Apple Powerbooks Fn key patch. Moving a few lines of code from the
'default' switch case to the new location makes it work again.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
Index: linux-2.6.12-rc4-mm1/drivers/usb/input/hid-input.c
===
--- linux-2.6.12-rc4-mm1.orig/drivers/usb/input/hid-input.c 2005-08-02
09:44:28.0 +0200
+++ linux-2.6.12-rc4-mm1/drivers/usb/input/hid-input.c 2005-08-02
10:57:13.0 +0200
@@ -323,6 +323,11 @@
case HID_UP_MSVENDOR:
case HID_UP_LOGIVENDOR:
+
+ if ((device->quirks & HID_QUIRK_POWERBOOK_FN_BUTTON) &&
(usage->hid == 0x00ff0003)) {
+ map_key_clear(KEY_RIGHTCTRL);
+ break;
+ }
goto ignore;
case HID_UP_LOGIVENDOR2: /* Reported on Logitech Ultra X Media
Remote */
@@ -376,10 +381,7 @@
default:
unknown:
- if ((device->quirks & HID_QUIRK_POWERBOOK_FN_BUTTON) &&
(usage->hid == 0x00ff0003)) {
- map_key_clear(KEY_RIGHTCTRL);
- break;
- }
+
if (field->report_size == 1) {
if (field->report->type == HID_OUTPUT_REPORT) {
map_led(LED_MISC);
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Le lundi 01 août 2005 à 16:37 +0200, Stelian Pop a écrit :
Also, it looks like sonypi really is pretty nasty to probe for, so it's
not enough to just say oh, it's a sony VAIO, let's reserve that region.
Otherwise I'd just suggest adding a dmi_check_system() table to
arch/i386/pci/i386.c, at the top of pcibios_assign_resources(), and
then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
I had no feedback at all on the patch so I have no idea if this will go
in or not, but since Eric's patch was accepted into -mm I rediffed the
patch in order to ease the testing (in case someone is willing to test
it).
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
arch/i386/pci/i386.c | 42 +
drivers/char/sonypi.c | 71 ++
2 files changed, 57 insertions(+), 56 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-08-02 10:21:58.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-02 10:28:26.0 +0200
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/ioport.h
#include linux/errno.h
+#include linux/dmi.h
#include pci.h
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, Sony Programable I/O Type1 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type1 IO region\n);
+
+ /* IO ports for 'type2' and 'type3' devices */
+ if (!request_region(0x1080, 0x20, Sony Programable I/O Type2 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type2 IO region\n);
+
+ printk(KERN_INFO Sony Vaio: pre-reserved IO ports\n);
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, PCG-),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, VGN-),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev-class 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-02 10:22:18.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:27:28.0 +0200
@@ -105,7 +105,9 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_TYPE1_BASE 0x50
#define SONYPI_G10A(SONYPI_TYPE1_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
@@ -113,13 +115,18 @@
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* type3 series specifics */
#define SONYPI_TYPE3_BASE 0x40
#define SONYPI_TYPE3_GID2 (SONYPI_TYPE3_BASE+0x48) /* 16 bits */
#define SONYPI_TYPE3_MISC
[PATCH] sonypi: remove obsolete event
I had this one in my tree for a long time, please apply.
Stelian.
Remove old obsolete event.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-02 10:22:15.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:22:18.0 +0200
@@ -406,7 +406,6 @@
{ SONYPI_DEVICE_MODEL_TYPE2, 0x31, SONYPI_BLUETOOTH_MASK, sonypi_blueev
},
{ SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_PKEY_MASK, sonypi_pkeyev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x11, SONYPI_BACK_MASK, sonypi_backev },
- { SONYPI_DEVICE_MODEL_TYPE2, 0x08, SONYPI_HELP_MASK, sonypi_helpev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x21, SONYPI_HELP_MASK, sonypi_helpev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x21, SONYPI_ZOOM_MASK, sonypi_zoomev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x20, SONYPI_THUMBPHRASE_MASK,
sonypi_thumbphraseev },
--
Stelian Pop [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] meye: use dma-mapping constants
Hi, This patch comes from the janitors and have been in my tree for quite some time now. Please apply. Stelian. Use the DMA_32BIT_MASK constant from dma-mapping.h when calling pci_set_dma_mask() or pci_set_consistent_dma_mask() This patch includes dma-mapping.h explicitly because it caused errors on some architectures otherwise. See http://marc.theaimsgroup.com/?t=10800199301r=1w=2 for details Signed-off-by: Tobias Klauser [EMAIL PROTECTED] Signed-off-by: Stelian Pop [EMAIL PROTECTED] Index: linux-2.6.git/drivers/media/video/meye.c === --- linux-2.6.git.orig/drivers/media/video/meye.c 2005-07-08 14:08:17.0 +0200 +++ linux-2.6.git/drivers/media/video/meye.c2005-08-02 10:22:23.0 +0200 @@ -37,6 +37,7 @@ #include linux/delay.h #include linux/interrupt.h #include linux/vmalloc.h +#include linux/dma-mapping.h #include meye.h #include linux/meye.h @@ -121,7 +122,7 @@ memset(meye.mchip_ptable, 0, sizeof(meye.mchip_ptable)); /* give only 32 bit DMA addresses */ - if (dma_set_mask(meye.mchip_dev-dev, 0x)) + if (dma_set_mask(meye.mchip_dev-dev, DMA_32BIT_MASK)) return -1; meye.mchip_ptable_toc = dma_alloc_coherent(meye.mchip_dev-dev, -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fn key and 2.6.12-rc4
Le mardi 02 août 2005 à 09:17 +0200, Elimar Riesebieter a écrit :
[ fnkey not working on Apple Powerbooks in -mm tree ]
Hmm, there seem to be a lot of divergence between -mm and linus tree
here, and this may be the cause of the malfunction.
Let me do some tests tomorrow with an -mm kernel and see if I find
something.
Ok, the -mm tree contains some other input patches which conflict with
my Fn key patch
(input-quirk-for-the-fn-key-on-powerbooks-with-an-usb.patch). The
attached patch makes it work again.
Andrew, please apply.
Stelian.
Newer input patches added a HID_UP_LOGIVENDOR switch case which disrupts
the Apple Powerbooks Fn key patch. Moving a few lines of code from the
'default' switch case to the new location makes it work again.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
Index: linux-2.6.12-rc4-mm1/drivers/usb/input/hid-input.c
===
--- linux-2.6.12-rc4-mm1.orig/drivers/usb/input/hid-input.c 2005-08-02
09:44:28.0 +0200
+++ linux-2.6.12-rc4-mm1/drivers/usb/input/hid-input.c 2005-08-02
10:57:13.0 +0200
@@ -323,6 +323,11 @@
case HID_UP_MSVENDOR:
case HID_UP_LOGIVENDOR:
+
+ if ((device-quirks HID_QUIRK_POWERBOOK_FN_BUTTON)
(usage-hid == 0x00ff0003)) {
+ map_key_clear(KEY_RIGHTCTRL);
+ break;
+ }
goto ignore;
case HID_UP_LOGIVENDOR2: /* Reported on Logitech Ultra X Media
Remote */
@@ -376,10 +381,7 @@
default:
unknown:
- if ((device-quirks HID_QUIRK_POWERBOOK_FN_BUTTON)
(usage-hid == 0x00ff0003)) {
- map_key_clear(KEY_RIGHTCTRL);
- break;
- }
+
if (field-report_size == 1) {
if (field-report-type == HID_OUTPUT_REPORT) {
map_led(LED_MISC);
--
Stelian Pop [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: powerbook power-off and 2.6.13-rc[3,4]
Le mardi 02 août 2005 à 13:38 +0200, Johannes Berg a écrit : Pavel Machek wrote: Can you try without USB? Not really. The keyboard is USB, and there's no PS/2 connector. I guess I maybe could do it via a timer, unload the modules and then have it shut down afterwards... I'll build a kernel without USB and drive the laptop over the net and see what happens. With USB but without experimental CONFIG_USB_SUSPEND? I don't have USB_SUSPEND enabled, IIRC (don't have the PB with me, but I'm pretty sure I checked this yesterday. If you don't hear back, assume it wasn't enabled) I don't have USB_SUSPEND enabled. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerbook power-off and 2.6.13-rc[3,4]
Le mardi 02 août 2005 à 13:43 +0200, Stelian Pop a écrit : Pavel Machek wrote: Can you try without USB? Not really. The keyboard is USB, and there's no PS/2 connector. I guess I maybe could do it via a timer, unload the modules and then have it shut down afterwards... I'll build a kernel without USB and drive the laptop over the net and see what happens. Without CONFIG_USB the poweroff still hangs, and this time the panel goes completly white with dark spots appearing all over it (kinda scary btw). A 5 seconds press on the power button force it to power off. This is on a 2.6.13-rc4, and I'm attaching the .config in case it matters. Stelian. -- Stelian Pop [EMAIL PROTECTED] CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_TAU=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_PMAC=y CONFIG_PM=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_PREP=y CONFIG_PPC_OF=y CONFIG_PPCBUG_NVRAM=y CONFIG_HIGHMEM=y CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_PREEMPT_NONE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_BINFMT_ELF=y CONFIG_PROC_DEVICETREE=y CONFIG_PREP_RESIDUAL=y CONFIG_PROC_PREPRESIDUAL=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE=console=ttyS0,9600 console=tty0 root=/dev/sda2 CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y CONFIG_YENTA=y CONFIG_PCCARD_NONSTATIC=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIB_HASH=y CONFIG_TCP_CONG_BIC=y CONFIG_NETFILTER=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_MATCH_ADDRTYPE=y CONFIG_IP_NF_MATCH_REALM=y CONFIG_IP_NF_MATCH_SCTP=y CONFIG_IP_NF_MATCH_COMMENT=y CONFIG_IP_NF_MATCH_HASHLIMIT=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_NET_CLS_ROUTE=y CONFIG_BT=y CONFIG_BT_L2CAP=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_HIDP=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_BLK_DEV_IDEDMA_PMAC=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_SG=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_FC_ATTRS=y CONFIG_SCSI_QLA2XXX=y CONFIG_IEEE1394=y CONFIG_IEEE1394_OUI_DB=y CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
Re: powerbook power-off and 2.6.13-rc[3,4]
Le mardi 02 août 2005 à 14:54 +0200, Pavel Machek a écrit : Hi! Pavel Machek wrote: Can you try without USB? Not really. The keyboard is USB, and there's no PS/2 connector. I guess I maybe could do it via a timer, unload the modules and then have it shut down afterwards... I'll build a kernel without USB and drive the laptop over the net and see what happens. Without CONFIG_USB the poweroff still hangs, and this time the panel goes completly white with dark spots appearing all over it (kinda scary btw). A 5 seconds press on the power button force it to power off. Yep, looks like screen burning, right? Exactly. So it is different kind of hang = USB has some problem but there's another one, too? Seems that this is the case, yes. This is on a 2.6.13-rc4, and I'm attaching the .config in case it matters. Could you try inserting printks to see where it hangs? Aha, with display turned off that is not going to be funny. Unfortunately I won't have time to debug this right now (I leave on vacation tomorrow), so somebody else will have to do it (and no, it is not going to be funny to do this without display, serial port, buzzer etc) Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerbook power-off and 2.6.13-rc[3,4]
Le lundi 01 août 2005 à 16:07 +0200, Johannes Berg a écrit : > On Mon, 2005-08-01 at 15:54 +0200, Antonio-M. Corbi Bellot wrote: > > > Has anyone observed this behaviour (O.S. halt ok but _no_ power-off at > > the end) with these new '-rc' kernels? > > Yes. I haven't looked for the cause yet though. I found that if you comment the device_suspend(PMSG_SUSPEND); line in kernel/sys.c, in the kernel_power_off() function, then it works again, but I haven't had the time to look further. I've put LKML in CC: in case this rings someone's bell. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
[Sorry all for the duplicate, LKML slipped somehow from the CC: line so I'm
sending this again]
Le dimanche 31 juillet 2005 à 16:22 -0700, Linus Torvalds a écrit :
> Also, it looks like sonypi really is pretty nasty to probe for, so it's
> not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> Otherwise I'd just suggest adding a "dmi_check_system()" table to
> arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
arch/i386/pci/i386.c | 42 +++
drivers/char/sonypi.c | 60 --
2 files changed, 52 insertions(+), 50 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-07-08 14:08:10.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-01 15:46:06.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "pci.h"
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, "Sony Programable I/O Type1 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type1 IO region\n");
+
+ /* IO ports for 'type2' device */
+ if (!request_region(0x1080, 0x20, "Sony Programable I/O Type2 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type2 IO region\n");
+
+ printk(KERN_INFO "Sony Vaio: pre-reserved IO ports\n");
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PCG-"),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-"),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev->class >> 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-01 11:06:47.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-01 15:45:27.0 +0200
@@ -104,14 +104,18 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_BASE0x50
#define SONYPI_G10A(SONYPI_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
#define SONYPI_SIRQ0x9b
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
-#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* battery / brightness addresses */
@@ -136,29 +140,6 @@
#define SONYPI_DATA_IOPORT 0x62
#define SONYPI_CST_IOPORT 0
Re: [PATCH] sonypi, kernel 2.6.12.3
Le lundi 01 août 2005 à 02:59 +0200, Erik Waling a écrit : > Newer Sony VAIO models (VGN-S480, VGN-S460, VGN-S3XP etc) use a new method to > initialize the SPIC device. The new way to initialize (and disable) the device > comes directly from the AML code in the _CRS, _SRS and _DIS methods from the > DSDT table. This patch against 2.6.12.3 adds support for the new models. > > -- Erik Waling <[EMAIL PROTECTED]> > > > > --- linux-2.6.12.3/drivers/char/sonypi.c 2005-07-15 16:18:57.0 > -0500 > +++ linux/drivers/char/sonypi.c 2005-07-31 16:55:41.0 -0500 [...] > + - some models with the nvidia card (geforce go 6200 tc) uses a > + different way to adjust the backlighting of the screen. There > + is a userspace utility to adjust the brightness on those models. Don't be shy, put the URL pointing to your SmartDimmer here :) Otherwise you have my: Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Thanks Erik. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sonypi, kernel 2.6.12.3
Le lundi 01 août 2005 à 02:59 +0200, Erik Waling a écrit : Newer Sony VAIO models (VGN-S480, VGN-S460, VGN-S3XP etc) use a new method to initialize the SPIC device. The new way to initialize (and disable) the device comes directly from the AML code in the _CRS, _SRS and _DIS methods from the DSDT table. This patch against 2.6.12.3 adds support for the new models. -- Erik Waling [EMAIL PROTECTED] --- linux-2.6.12.3/drivers/char/sonypi.c 2005-07-15 16:18:57.0 -0500 +++ linux/drivers/char/sonypi.c 2005-07-31 16:55:41.0 -0500 [...] + - some models with the nvidia card (geforce go 6200 tc) uses a + different way to adjust the backlighting of the screen. There + is a userspace utility to adjust the brightness on those models. Don't be shy, put the URL pointing to your SmartDimmer here :) Otherwise you have my: Signed-off-by: Stelian Pop [EMAIL PROTECTED] Thanks Erik. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
[Sorry all for the duplicate, LKML slipped somehow from the CC: line so I'm
sending this again]
Le dimanche 31 juillet 2005 à 16:22 -0700, Linus Torvalds a écrit :
Also, it looks like sonypi really is pretty nasty to probe for, so it's
not enough to just say oh, it's a sony VAIO, let's reserve that region.
Otherwise I'd just suggest adding a dmi_check_system() table to
arch/i386/pci/i386.c, at the top of pcibios_assign_resources(), and
then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
arch/i386/pci/i386.c | 42 +++
drivers/char/sonypi.c | 60 --
2 files changed, 52 insertions(+), 50 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-07-08 14:08:10.0
+0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-01 15:46:06.0 +0200
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/ioport.h
#include linux/errno.h
+#include linux/dmi.h
#include pci.h
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, Sony Programable I/O Type1 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type1 IO region\n);
+
+ /* IO ports for 'type2' device */
+ if (!request_region(0x1080, 0x20, Sony Programable I/O Type2 Device))
+ printk(KERN_ERR Sony Vaio: cannot reserve Type2 IO region\n);
+
+ printk(KERN_INFO Sony Vaio: pre-reserved IO ports\n);
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, PCG-),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = Sony Vaio Laptop,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Sony Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME, VGN-),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev-class 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===
--- linux-2.6.git.orig/drivers/char/sonypi.c2005-08-01 11:06:47.0
+0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-01 15:45:27.0 +0200
@@ -104,14 +104,18 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_BASE0x50
#define SONYPI_G10A(SONYPI_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
#define SONYPI_SIRQ0x9b
#define SONYPI_SLOB0x9c
#define SONYPI_SHIB0x9d
-#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* battery / brightness addresses */
@@ -136,29 +140,6 @@
#define SONYPI_DATA_IOPORT 0x62
#define SONYPI_CST_IOPORT 0x66
-/* The set of possible ioports */
-struct sonypi_ioport_list {
- u16 port1;
- u16 port2;
-};
-
-static struct sonypi_ioport_list
Re: powerbook power-off and 2.6.13-rc[3,4]
Le lundi 01 août 2005 à 16:07 +0200, Johannes Berg a écrit : On Mon, 2005-08-01 at 15:54 +0200, Antonio-M. Corbi Bellot wrote: Has anyone observed this behaviour (O.S. halt ok but _no_ power-off at the end) with these new '-rc' kernels? Yes. I haven't looked for the cause yet though. I found that if you comment the device_suspend(PMSG_SUSPEND); line in kernel/sys.c, in the kernel_power_off() function, then it works again, but I haven't had the time to look further. I've put LKML in CC: in case this rings someone's bell. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Le dimanche 31 juillet 2005 à 11:25 -0700, Linus Torvalds a écrit : > - The SonyPI driver just allocates IO regions in random areas. Those are not really random, the list of IO regions available is given in the ACPI SPIC device specification. The list is hardcoded here because the driver does not (yet ?) use the ACPI services for initializing the device, and experience has shown that the list does not vary with different models. > and I think the real bug here is the SonyPI driver. > > It should either use an IO port in the legacy motherboard resource area > (ie allocate itself somewhere in IO ports 0x100-0x3ff), this cannot be done, because the regions are already defined, and are not in the legacy area. > _or_ it should > play well as a PCI device, and actually try to work with the PCI IO port > allocation layer. sure, but the SPIC device is not really tied to a specific PCI device (it is for the 'type1' models, but not for the 'type2' ones). That's why the sonypi driver is not a PCI driver but relies on a DMI ident to detect each and every Vaio laptop out there. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Le dimanche 31 juillet 2005 à 11:25 -0700, Linus Torvalds a écrit : - The SonyPI driver just allocates IO regions in random areas. Those are not really random, the list of IO regions available is given in the ACPI SPIC device specification. The list is hardcoded here because the driver does not (yet ?) use the ACPI services for initializing the device, and experience has shown that the list does not vary with different models. and I think the real bug here is the SonyPI driver. It should either use an IO port in the legacy motherboard resource area (ie allocate itself somewhere in IO ports 0x100-0x3ff), this cannot be done, because the regions are already defined, and are not in the legacy area. _or_ it should play well as a PCI device, and actually try to work with the PCI IO port allocation layer. sure, but the SPIC device is not really tied to a specific PCI device (it is for the 'type1' models, but not for the 'type2' ones). That's why the sonypi driver is not a PCI driver but relies on a DMI ident to detect each and every Vaio laptop out there. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input quirk for the Fn key on Powerbooks with an USB keyboard
Hi,
On newer Apple Powerbooks (post February 2005 ones at least) the ADB
keyboard has been replaced with an USB one conforming to the HID spec.
The 'Fn' modifier key on this keyboard is a soft key reported using an
application specific hid code. This key should act as a modifier in
order to make Home/End/Page Up/Page Down etc. work.
The attached patch makes the Fn key report a modifier keycode
(KEY_RIGHTCTRL) to the input layer by adding a quirk to the USB HID
input driver. Johannes Berg <[EMAIL PROTECTED]> should be
credited for the original version of this patch.
'Right control' is not the best choice for this key, especially since it
is physically placed on the keyboard on the left bottom corner. However,
this laptop already has left shift, control, alt and meta (apple) keys,
and right meta and shift keys. The only modifiers left are 'right
control' and 'right alt' and the first one was chosen. Choosing an
already defined modifier key eases the handling of this key especially
in X (where it can be mapped to SuperL or whatever).
Comments welcomed.
Thanks,
Stelian.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
hid-core.c |7 +++
hid-input.c |8
hid.h |1 +
3 files changed, 16 insertions(+)
Index: linux-2.6.git/drivers/usb/input/hid-core.c
===
--- linux-2.6.git.orig/drivers/usb/input/hid-core.c 2005-07-28
09:35:52.0 +0200
+++ linux-2.6.git/drivers/usb/input/hid-core.c 2005-07-28 12:22:31.0
+0200
@@ -1446,6 +1446,10 @@
* Alphabetically sorted blacklist by quirk type.
*/
+#define USB_VENDOR_ID_APPLE0x05AC
+#define USB_DEVICE_ID_POWERBOOK_KB_US 0x020E
+#define USB_DEVICE_ID_POWERBOOK_KB_UK 0x020F
+
static struct hid_blacklist {
__u16 idVendor;
__u16 idProduct;
@@ -1557,6 +1561,9 @@
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_POWERBOOK_KB_US,
HID_QUIRK_POWERBOOK_FN_BUTTON },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_POWERBOOK_KB_UK,
HID_QUIRK_POWERBOOK_FN_BUTTON },
+
{ 0, 0 }
};
Index: linux-2.6.git/drivers/usb/input/hid-input.c
===
--- linux-2.6.git.orig/drivers/usb/input/hid-input.c2005-07-28
09:35:52.0 +0200
+++ linux-2.6.git/drivers/usb/input/hid-input.c 2005-07-28 12:23:14.0
+0200
@@ -106,6 +106,10 @@
} else
map_key(KEY_UNKNOWN);
+ if ((device->quirks & HID_QUIRK_POWERBOOK_FN_BUTTON) &&
+ (hid_keyboard[usage->hid & HID_USAGE] ==
KEY_RIGHTCTRL))
+ map_key(KEY_UNKNOWN);
+
break;
case HID_UP_BUTTON:
@@ -324,6 +328,10 @@
default:
unknown:
+ if ((device->quirks & HID_QUIRK_POWERBOOK_FN_BUTTON) &&
(usage->hid == 0x00ff0003)) {
+ map_key_clear(KEY_RIGHTCTRL);
+ break;
+ }
if (field->report_size == 1) {
if (field->report->type == HID_OUTPUT_REPORT) {
map_led(LED_MISC);
Index: linux-2.6.git/drivers/usb/input/hid.h
===
--- linux-2.6.git.orig/drivers/usb/input/hid.h 2005-07-28 09:35:52.0
+0200
+++ linux-2.6.git/drivers/usb/input/hid.h 2005-07-28 12:22:31.0
+0200
@@ -242,6 +242,7 @@
#define HID_QUIRK_2WHEEL_MOUSE_HACK_7 0x080
#define HID_QUIRK_2WHEEL_MOUSE_HACK_5 0x100
#define HID_QUIRK_2WHEEL_MOUSE_HACK_ON 0x200
+#define HID_QUIRK_POWERBOOK_FN_BUTTON 0x400
/*
* This is the global environment of the parser. This information is
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input quirk for the Fn key on Powerbooks with an USB keyboard
Hi,
On newer Apple Powerbooks (post February 2005 ones at least) the ADB
keyboard has been replaced with an USB one conforming to the HID spec.
The 'Fn' modifier key on this keyboard is a soft key reported using an
application specific hid code. This key should act as a modifier in
order to make Home/End/Page Up/Page Down etc. work.
The attached patch makes the Fn key report a modifier keycode
(KEY_RIGHTCTRL) to the input layer by adding a quirk to the USB HID
input driver. Johannes Berg [EMAIL PROTECTED] should be
credited for the original version of this patch.
'Right control' is not the best choice for this key, especially since it
is physically placed on the keyboard on the left bottom corner. However,
this laptop already has left shift, control, alt and meta (apple) keys,
and right meta and shift keys. The only modifiers left are 'right
control' and 'right alt' and the first one was chosen. Choosing an
already defined modifier key eases the handling of this key especially
in X (where it can be mapped to SuperL or whatever).
Comments welcomed.
Thanks,
Stelian.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
hid-core.c |7 +++
hid-input.c |8
hid.h |1 +
3 files changed, 16 insertions(+)
Index: linux-2.6.git/drivers/usb/input/hid-core.c
===
--- linux-2.6.git.orig/drivers/usb/input/hid-core.c 2005-07-28
09:35:52.0 +0200
+++ linux-2.6.git/drivers/usb/input/hid-core.c 2005-07-28 12:22:31.0
+0200
@@ -1446,6 +1446,10 @@
* Alphabetically sorted blacklist by quirk type.
*/
+#define USB_VENDOR_ID_APPLE0x05AC
+#define USB_DEVICE_ID_POWERBOOK_KB_US 0x020E
+#define USB_DEVICE_ID_POWERBOOK_KB_UK 0x020F
+
static struct hid_blacklist {
__u16 idVendor;
__u16 idProduct;
@@ -1557,6 +1561,9 @@
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_POWERBOOK_KB_US,
HID_QUIRK_POWERBOOK_FN_BUTTON },
+ { USB_VENDOR_ID_APPLE, USB_DEVICE_ID_POWERBOOK_KB_UK,
HID_QUIRK_POWERBOOK_FN_BUTTON },
+
{ 0, 0 }
};
Index: linux-2.6.git/drivers/usb/input/hid-input.c
===
--- linux-2.6.git.orig/drivers/usb/input/hid-input.c2005-07-28
09:35:52.0 +0200
+++ linux-2.6.git/drivers/usb/input/hid-input.c 2005-07-28 12:23:14.0
+0200
@@ -106,6 +106,10 @@
} else
map_key(KEY_UNKNOWN);
+ if ((device-quirks HID_QUIRK_POWERBOOK_FN_BUTTON)
+ (hid_keyboard[usage-hid HID_USAGE] ==
KEY_RIGHTCTRL))
+ map_key(KEY_UNKNOWN);
+
break;
case HID_UP_BUTTON:
@@ -324,6 +328,10 @@
default:
unknown:
+ if ((device-quirks HID_QUIRK_POWERBOOK_FN_BUTTON)
(usage-hid == 0x00ff0003)) {
+ map_key_clear(KEY_RIGHTCTRL);
+ break;
+ }
if (field-report_size == 1) {
if (field-report-type == HID_OUTPUT_REPORT) {
map_led(LED_MISC);
Index: linux-2.6.git/drivers/usb/input/hid.h
===
--- linux-2.6.git.orig/drivers/usb/input/hid.h 2005-07-28 09:35:52.0
+0200
+++ linux-2.6.git/drivers/usb/input/hid.h 2005-07-28 12:22:31.0
+0200
@@ -242,6 +242,7 @@
#define HID_QUIRK_2WHEEL_MOUSE_HACK_7 0x080
#define HID_QUIRK_2WHEEL_MOUSE_HACK_5 0x100
#define HID_QUIRK_2WHEEL_MOUSE_HACK_ON 0x200
+#define HID_QUIRK_POWERBOOK_FN_BUTTON 0x400
/*
* This is the global environment of the parser. This information is
--
Stelian Pop [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le mardi 12 juillet 2005 à 20:13 +0200, Vojtech Pavlik a écrit : > Stelian, can you please update the patch to use usb_to_input_id()? It'll > go through -mm first, anyway, so there shouldn't be any issue with > Linus's kernels not having that function yet. Sure, here it comes. Stelian. Changes: * removed local version number * use usb_to_input_id() instead of manually setting the fields Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Documentation/input/appletouch.txt | 84 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 467 + 4 files changed, 571 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-12 09:49:17.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-12 09:49:17.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate "Apple USB Touchpad support" + depends on USB && INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + . + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-12 10:22:23.0 +0200 @@ -0,0 +1,84 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]> + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling, 2 finger +tap for middle button mouse emulation, 3 finger tap for right button mouse +emulation, etc. In order to do this, make sure you're using a recent version of +the synaptics driver (tested with 0.14.2, available from [2]), and configure a +new input device in your X11 configuration file (take a look below for an +example). For additional configuration, see the synaptics driver documentation. + + Section "InputDevice" + Identifier "Synaptics Touchpad" + Driver "synaptics" + Option "SendCoreEvents""true" + Option "Device""/dev/input/mice" + Option "Protocol" "auto-dev" + Option "LeftEdge" "0" + Option "RightEdge" "850" + Option "TopEdge" "0" + Option "BottomEdge""645"
Re: [PATCH] Apple USB Touchpad driver (new)
Le mardi 12 juillet 2005 à 09:13 -0500, Dmitry Torokhov a écrit : > Hi, > > On 7/12/05, Stelian Pop <[EMAIL PROTECTED]> wrote: > > > > + dev->input.id.bustype = BUS_USB; > > + dev->input.id.vendor = id->idVendor; > > + dev->input.id.product = id->idProduct; > > + dev->input.id.version = ATP_DRIVER_VERSION; > > + > > Why don't we do what most of the other input devices and get version > from the device too? I guess we could, there is not much use for a local driver version anyway. > Actually we have this in input tree: > > static inline void > usb_to_input_id(const struct usb_device *dev, struct input_id *id) This cleans up a lot of code indeed. Too bad this is not upstream yet... Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 13:21 +0200, Vojtech Pavlik a écrit : > > > This could be quite useful, too, for right and middle button taps (2 and > > > 3 fingers) - since the Macs lack these buttons. > > > > Indeed. But this can be a later improvement, let's make one finger work > > for now :) Thanks to Peter Osterlund, I now have 2 and 3 finger tap working. Please apply the attached patch. Thanks, Stelian. Changes: * implement detection of 2 and 3 finger tap (thanks to Peter Osterlund) * moved the static variables into the atp device structure * print the timestamp in debug messages Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Documentation/input/appletouch.txt | 84 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 471 + 4 files changed, 575 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-12 09:49:17.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-12 09:49:17.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate "Apple USB Touchpad support" + depends on USB && INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + . + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-12 10:22:23.0 +0200 @@ -0,0 +1,84 @@ +Apple Touchpad Driver (appletouch) +---------- + Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]> + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling, 2 finger +tap for middle button mouse emulation, 3 finger tap for right button mouse +emulation, etc. In order to do this, make sure you're using a recent version of +the synaptics driver (tested with 0.14.2, available from [2]), and configure a +new input device in your X11 configuration file (take a look below for an +example). For additional configuration, see the synaptics driver documentation. + + Section "InputDevice" + Identifier "Synaptics Touchpad" + Driver "synaptics" + Option "SendCoreEvents""true" + Option "Device""/dev/input/mice" + Option "Protocol" "auto-dev" + Option "LeftEdge" "0" +
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 13:21 +0200, Vojtech Pavlik a écrit : This could be quite useful, too, for right and middle button taps (2 and 3 fingers) - since the Macs lack these buttons. Indeed. But this can be a later improvement, let's make one finger work for now :) Thanks to Peter Osterlund, I now have 2 and 3 finger tap working. Please apply the attached patch. Thanks, Stelian. Changes: * implement detection of 2 and 3 finger tap (thanks to Peter Osterlund) * moved the static variables into the atp device structure * print the timestamp in debug messages Signed-off-by: Stelian Pop [EMAIL PROTECTED] Documentation/input/appletouch.txt | 84 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 471 + 4 files changed, 575 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-12 09:49:17.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-12 09:49:17.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate Apple USB Touchpad support + depends on USB INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + file:Documentation/input/appletouch.txt. + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-12 10:22:23.0 +0200 @@ -0,0 +1,84 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop [EMAIL PROTECTED] + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling, 2 finger +tap for middle button mouse emulation, 3 finger tap for right button mouse +emulation, etc. In order to do this, make sure you're using a recent version of +the synaptics driver (tested with 0.14.2, available from [2]), and configure a +new input device in your X11 configuration file (take a look below for an +example). For additional configuration, see the synaptics driver documentation. + + Section InputDevice + Identifier Synaptics Touchpad + Driver synaptics + Option SendCoreEventstrue + Option Device/dev/input/mice + Option Protocol auto-dev + Option LeftEdge 0 + Option RightEdge 850 + Option TopEdge 0 + Option BottomEdge645 + Option
Re: [PATCH] Apple USB Touchpad driver (new)
Le mardi 12 juillet 2005 à 09:13 -0500, Dmitry Torokhov a écrit : Hi, On 7/12/05, Stelian Pop [EMAIL PROTECTED] wrote: + dev-input.id.bustype = BUS_USB; + dev-input.id.vendor = id-idVendor; + dev-input.id.product = id-idProduct; + dev-input.id.version = ATP_DRIVER_VERSION; + Why don't we do what most of the other input devices and get version from the device too? I guess we could, there is not much use for a local driver version anyway. Actually we have this in input tree: static inline void usb_to_input_id(const struct usb_device *dev, struct input_id *id) This cleans up a lot of code indeed. Too bad this is not upstream yet... Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le mardi 12 juillet 2005 à 20:13 +0200, Vojtech Pavlik a écrit : Stelian, can you please update the patch to use usb_to_input_id()? It'll go through -mm first, anyway, so there shouldn't be any issue with Linus's kernels not having that function yet. Sure, here it comes. Stelian. Changes: * removed local version number * use usb_to_input_id() instead of manually setting the fields Signed-off-by: Stelian Pop [EMAIL PROTECTED] Documentation/input/appletouch.txt | 84 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 467 + 4 files changed, 571 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-12 09:49:17.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-12 09:47:53.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-12 09:49:17.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate Apple USB Touchpad support + depends on USB INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + file:Documentation/input/appletouch.txt. + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-12 10:22:23.0 +0200 @@ -0,0 +1,84 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop [EMAIL PROTECTED] + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling, 2 finger +tap for middle button mouse emulation, 3 finger tap for right button mouse +emulation, etc. In order to do this, make sure you're using a recent version of +the synaptics driver (tested with 0.14.2, available from [2]), and configure a +new input device in your X11 configuration file (take a look below for an +example). For additional configuration, see the synaptics driver documentation. + + Section InputDevice + Identifier Synaptics Touchpad + Driver synaptics + Option SendCoreEventstrue + Option Device/dev/input/mice + Option Protocol auto-dev + Option LeftEdge 0 + Option RightEdge 850 + Option TopEdge 0 + Option BottomEdge645 + Option MinSpeed 0.4 + Option MaxSpeed 1 + Option AccelFactor 0.02 + Option FingerLow 0
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 16:44 -0400, Lee Revell a écrit : > On Mon, 2005-07-11 at 13:04 +0200, Stelian Pop wrote: > > Oops, bad Evolution (even if I did use insert->text file for the patch). > > > > Going back to mutt. Sorry about this. > > There's no need to go back to mutt, Evolution is not broken. Before > doing 'Insert->Text File', you just have to change the text style at the > insertion point from 'Normal' to 'Preformat' to avoid word-wrapping the > patch. Indeed, Alexander Nyberg already pointed this to me in private. Thanks. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 14:47 +0200, Stelian Pop a écrit : > How to make it work ? Obviously I could implement either fuzz > elimination or smoothing in the driver, and leave the other > transformation to the input core (today it is the smoothing which is in > the driver, but doing it the other way around would result in much less > code). And of course it cannot be done without modifying input core in order to prevent it throwing away the samples. The only way to manage the current situation is to implement smoothing in the driver itself (but I used the same algorithm as in the input core, thus removing the unneeded history) > > > > > I don't think this value is reliable enough to be reported to the > > > > > userspace as ABS_PRESSURE... > > > > > > > > I believe it'd still be more useful than a two-value (0 and 100) output. > > > > > > Ok, I'll do it. Implemented too. Here is the latest incarnation of the patch, please apply this one. If Vojtech decides that it makes sense to modify the input core in order to separate fuzz and smoothing, then the driver could be simplified a bit more. Thanks, Stelian. Changes: * report ABS_PRESSURE events * simplify smoothing by using the same technique as the input core eliminating the need for a FIFO. Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Documentation/input/appletouch.txt | 83 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 480 + 4 files changed, 583 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-11 09:48:23.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-11 09:48:23.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate "Apple USB Touchpad support" + depends on USB && INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + . + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-11 15:02:51.0 +0200 @@ -0,0 +1,83 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]> + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configu
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 13:21 +0200, Vojtech Pavlik a écrit : > On Mon, Jul 11, 2005 at 01:08:35PM +0200, Stelian Pop wrote: > > > Possible. The 'fuzz' parameter in input core serves too many usages > > ihmo. Let me try removing the quick motion compensation and see... > > It was designed for joysticks and works very well for them. Usefulness > for other device types may vary. And I'll gladly accept patches to > improve it. Ok, I understand now what is happenning, but I'm not sure how to solve the problem. As I suspected, it is caused by 'fuzz' being a bit abused by the input core. The fuzz parameter in the input core is used today to say: * any change in the -fuzz/2 / +fuzz/2 range is ignored * any change in the -fuzz / +fuzz range is smoothed using x_old * 3 + x) / 4; * any change in the -fuzz*2 / +fuzz/2 range is smoothed using x_old +x) / 2; My driver needs to ignore changes in the -8 / +8 range (that's why I set FUZZ to 16 in the first place), but it needs to smooth the movement when much larger changes occur (I would need to set FUZZ to 64 for smoothing to work correctly here). How to make it work ? Obviously I could implement either fuzz elimination or smoothing in the driver, and leave the other transformation to the input core (today it is the smoothing which is in the driver, but doing it the other way around would result in much less code). The other (proper ?) solution would be to change the input core and separate fuzz and smoothing. This would however require an API addition, and I'm not sure you want to do that. If you do, I could work on a patch implementing an inputdev->abssmooth[] table, etc). > > I thought the hardware is capable of calculating real pressure... > > Since the sensor is just a multi-layer PCB with a clever trace layout, > it can't. > > > > > I don't think this value is reliable enough to be reported to the > > > > userspace as ABS_PRESSURE... > > > > > > I believe it'd still be more useful than a two-value (0 and 100) output. > > > > Ok, I'll do it. > > Thanks. Should I wait for that or apply the patch you just sent? Well, it depends on what we do with smoothing. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 13:00 +0200, Vojtech Pavlik a écrit : > On Mon, Jul 11, 2005 at 12:39:31PM +0200, Stelian Pop wrote: > > > > > Using a function like > > > > > > > > return (x_old * 3 + x) / 4; > > > > > > > > eliminates the need for a FIFO, and has similar (if not better) > > > > properties to floating average, because its coefficients are > > > > [ .25 .18 .14 .10 ... ]. > > > > > > Agreed. > > > > Except that this does not work well enough. > > I guess the quick motion compensation in input bites you. The above > equation should do even more smoothing than regular 4-point floating > average. Possible. The 'fuzz' parameter in input core serves too many usages ihmo. Let me try removing the quick motion compensation and see... > > I already thought about this, one problem is that the sensors do not > > report the pressure but only the amount of surface touched. A person > > with thick fingers will always generate higher pressures then one with > > thin ones, no matter how hard they push on the touchpad. > > That's what all other touchpads do. I thought the hardware is capable of calculating real pressure... > > I don't think this value is reliable enough to be reported to the > > userspace as ABS_PRESSURE... > > I believe it'd still be more useful than a two-value (0 and 100) output. Ok, I'll do it. > > + /* > > +* in the future, we could add here code to search for > > +* a second finger... > > +* for now, scrolling using the synaptics X driver is > > +* much more simpler to achieve. > > +*/ > > This could be quite useful, too, for right and middle button taps (2 and > 3 fingers) - since the Macs lack these buttons. Indeed. But this can be a later improvement, let's make one finger work for now :) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
On Mon, Jul 11, 2005 at 03:52:44AM -0700, Andrew Morton wrote: > Stelian Pop <[EMAIL PROTECTED]> wrote: > > > > Anyway, here is the updated patch: > > > > Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> > > > > Documentation/input/appletouch.txt | 83 ++ > > drivers/usb/input/Kconfig | 19 + > > drivers/usb/input/Makefile |1 > > drivers/usb/input/appletouch.c | 509 > > + > > Badly wordwrapped. Oops, bad Evolution (even if I did use insert->text file for the patch). Going back to mutt. Sorry about this. Changelog: * CodingStyle fixes * open counter replaced by a binary flag * udev hacks are no longer necessary with a patched synaptics, update the documentation Signed-off-by: Stelian Pop <[EMAIL PROTECTED]> Documentation/input/appletouch.txt | 83 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 509 + 4 files changed, 612 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-11 09:48:23.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-11 09:48:23.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate "Apple USB Touchpad support" + depends on USB && INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + . + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-11 11:57:41.0 +0200 @@ -0,0 +1,83 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]> + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation. + + Section "InputDevice" + Identifier "Synaptics Touchpad" + Driver "synaptics" + Option "SendCoreEvents""true" + Option "Device""/dev/input/mice" + Option "Protocol"
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 02:15 +0200, Peter Osterlund a écrit :
> Vojtech Pavlik <[EMAIL PROTECTED]> writes:
>
> > On Sun, Jul 10, 2005 at 12:48:30AM +0200, Peter Osterlund wrote:
> > > Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> > >
> > > > Btw, what I don't completely understand is why you need linear
> > > > regression, when you're not trying to detect motion or something like
> > > > that. Basic floating average, or even simpler filtering like the input
> > > > core uses for fuzz could work well enough I believe.
> > >
> > > Indeed, this function doesn't make much sense:
> > >
> > > +static inline int smooth_history(int x0, int x1, int x2, int x3)
> > > +{
> > > + return x0 - ( x0 * 3 + x1 - x2 - x3 * 3 ) / 10;
> > > +}
[...]
> +static inline int smooth_history(int x0, int x1, int x2, int x3)
> +{
> + return (x0 + x1 + x2 + x3) / 4;
> +}
I took Peter's approach here and changed the smoothing to use basic
floating average as above.
> > Using a function like
> >
> > return (x_old * 3 + x) / 4;
> >
> > eliminates the need for a FIFO, and has similar (if not better)
> > properties to floating average, because its coefficients are
> > [ .25 .18 .14 .10 ... ].
>
> Agreed.
Except that this does not work well enough.
There are two problems I encountered in this driver:
* fuzz problems (keeping the finger at the same place makes the pointer
dance around its position). This is solved by the input core's fuzz
treatment, as I already set the fuzz to 16 in the code.
* hickup problems (moving the finger generates non linear points,
something like 1 1 1 3 3 3 4 4 4 instead of 1 1 1 2 2 3 3 4 4). And here
the floating average approach works better than the input core's method.
(this could probably be solved also by changing the way the absolute
coordinate is calculated from the sensor array in atp_calculate_abs, but
I haven't been able to find a better linear function).
> I took the liberty to modify the patch myself, making these changes:
>
> * Removed the extra filtering.
> * Converted the "open" counter to an "open" flag. (It is still needed
> by the atp_resume() function.)
> * CodingStyle fixes.
>
> I have only compile tested this as I don't have access to the
> hardware, so I don't know how well this works in practice. It's
> possible that the "dev->h_count > 3" test in the old patch filtered
> out spikes in the input signal.
I would prefer to submit the patch myself, because as you say you cannot
test the code and those changes are rather sensitive. Without the
smoothing function, the driver is almost unusable when used without the
synaptics driver (as a standard mouse), positionning the pointer at
exact locations is quite difficult.
> Also, it might be a good idea to compute an ABS_PRESSURE value instead
> of hardcoding it to 100. I think the psum variable in
> atp_calculate_abs() can be used, possibly after rescaling.
I already thought about this, one problem is that the sensors do not
report the pressure but only the amount of surface touched. A person
with thick fingers will always generate higher pressures then one with
thin ones, no matter how hard they push on the touchpad.
I don't think this value is reliable enough to be reported to the
userspace as ABS_PRESSURE...
Anyway, here is the updated patch:
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
Documentation/input/appletouch.txt | 83 ++
drivers/usb/input/Kconfig | 19 +
drivers/usb/input/Makefile |1
drivers/usb/input/appletouch.c | 509
+
4 files changed, 612 insertions(+)
Index: linux-2.6.git/drivers/usb/input/Makefile
===
--- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-11
09:46:57.0 +0200
+++ linux-2.6.git/drivers/usb/input/Makefile2005-07-11
09:48:23.0 +0200
@@ -39,3 +39,4 @@
obj-$(CONFIG_USB_WACOM)+= wacom.o
obj-$(CONFIG_USB_ACECAD) += acecad.o
obj-$(CONFIG_USB_XPAD) += xpad.o
+obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o
Index: linux-2.6.git/drivers/usb/input/Kconfig
===
--- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-11
09:46:57.0 +0200
+++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-11
09:48:23.0 +0200
@@ -259,3 +259,22 @@
To compile this driver as a module, choose M here: the module will
be
called ati_remote.
+config USB_APPLETOUCH
+ tristate "Apple USB Touchpad support"
+ depends on USB && INPUT
+ ---help---
+ Say Y here if you want to
Re: [PATCH] Apple USB Touchpad driver (new)
Le dimanche 10 juillet 2005 à 00:32 +0200, Peter Osterlund a écrit :
> Stelian Pop <[EMAIL PROTECTED]> writes:
>
> > +Synaptics re-detection problems:
> > +
> > +
> > +The synaptics X11 driver tries to re-open the touchpad input device file
> > +(/dev/input/eventX) each time you change from text mode back to X11. If the
> > +input device file does not exist at this precise moment, the synaptics
> > driver
> > +will give up searching for a touchpad, permanently. You will need to
> > restart
> > +X11 if you want to reissue a scan.
>
> I think this particular problem is fixed by the following patch to the
> X driver:
>
> --- synaptics.c.old 2005-07-10 00:09:02.0 +0200
> +++ synaptics.c 2005-07-10 00:09:12.0 +0200
> @@ -524,6 +524,11 @@
>
> local->fd = xf86OpenSerial(local->options);
> if (local->fd == -1) {
> + xf86ReplaceStrOption(local->options, "Device", "");
> + SetDeviceAndProtocol(local);
> + local->fd = xf86OpenSerial(local->options);
> +}
> +if (local->fd == -1) {
> xf86Msg(X_WARNING, "%s: cannot open input device\n", local->name);
> return !Success;
> }
It does indeed fix the problem.
I removed that section from the documentation, as I assume you will
integrate this patch in future synaptics releases (and it wasn't anyway
a big problem for users, just for developers).
>
> > +static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact) {
>
> I think this CodingStyle violation is quite annoying, because it
> prevents emacs from finding the beginning of the function. It should
> be written like this:
Indeed, that one slipped over, but this didn't prevent vim from finding
the beginning of the function :)
Thanks,
Stelian.
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le dimanche 10 juillet 2005 à 00:32 +0200, Peter Osterlund a écrit :
Stelian Pop [EMAIL PROTECTED] writes:
+Synaptics re-detection problems:
+
+
+The synaptics X11 driver tries to re-open the touchpad input device file
+(/dev/input/eventX) each time you change from text mode back to X11. If the
+input device file does not exist at this precise moment, the synaptics
driver
+will give up searching for a touchpad, permanently. You will need to
restart
+X11 if you want to reissue a scan.
I think this particular problem is fixed by the following patch to the
X driver:
--- synaptics.c.old 2005-07-10 00:09:02.0 +0200
+++ synaptics.c 2005-07-10 00:09:12.0 +0200
@@ -524,6 +524,11 @@
local-fd = xf86OpenSerial(local-options);
if (local-fd == -1) {
+ xf86ReplaceStrOption(local-options, Device, );
+ SetDeviceAndProtocol(local);
+ local-fd = xf86OpenSerial(local-options);
+}
+if (local-fd == -1) {
xf86Msg(X_WARNING, %s: cannot open input device\n, local-name);
return !Success;
}
It does indeed fix the problem.
I removed that section from the documentation, as I assume you will
integrate this patch in future synaptics releases (and it wasn't anyway
a big problem for users, just for developers).
+static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact) {
I think this CodingStyle violation is quite annoying, because it
prevents emacs from finding the beginning of the function. It should
be written like this:
Indeed, that one slipped over, but this didn't prevent vim from finding
the beginning of the function :)
Thanks,
Stelian.
--
Stelian Pop [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 02:15 +0200, Peter Osterlund a écrit :
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Sun, Jul 10, 2005 at 12:48:30AM +0200, Peter Osterlund wrote:
Vojtech Pavlik [EMAIL PROTECTED] writes:
Btw, what I don't completely understand is why you need linear
regression, when you're not trying to detect motion or something like
that. Basic floating average, or even simpler filtering like the input
core uses for fuzz could work well enough I believe.
Indeed, this function doesn't make much sense:
+static inline int smooth_history(int x0, int x1, int x2, int x3)
+{
+ return x0 - ( x0 * 3 + x1 - x2 - x3 * 3 ) / 10;
+}
[...]
+static inline int smooth_history(int x0, int x1, int x2, int x3)
+{
+ return (x0 + x1 + x2 + x3) / 4;
+}
I took Peter's approach here and changed the smoothing to use basic
floating average as above.
Using a function like
return (x_old * 3 + x) / 4;
eliminates the need for a FIFO, and has similar (if not better)
properties to floating average, because its coefficients are
[ .25 .18 .14 .10 ... ].
Agreed.
Except that this does not work well enough.
There are two problems I encountered in this driver:
* fuzz problems (keeping the finger at the same place makes the pointer
dance around its position). This is solved by the input core's fuzz
treatment, as I already set the fuzz to 16 in the code.
* hickup problems (moving the finger generates non linear points,
something like 1 1 1 3 3 3 4 4 4 instead of 1 1 1 2 2 3 3 4 4). And here
the floating average approach works better than the input core's method.
(this could probably be solved also by changing the way the absolute
coordinate is calculated from the sensor array in atp_calculate_abs, but
I haven't been able to find a better linear function).
I took the liberty to modify the patch myself, making these changes:
* Removed the extra filtering.
* Converted the open counter to an open flag. (It is still needed
by the atp_resume() function.)
* CodingStyle fixes.
I have only compile tested this as I don't have access to the
hardware, so I don't know how well this works in practice. It's
possible that the dev-h_count 3 test in the old patch filtered
out spikes in the input signal.
I would prefer to submit the patch myself, because as you say you cannot
test the code and those changes are rather sensitive. Without the
smoothing function, the driver is almost unusable when used without the
synaptics driver (as a standard mouse), positionning the pointer at
exact locations is quite difficult.
Also, it might be a good idea to compute an ABS_PRESSURE value instead
of hardcoding it to 100. I think the psum variable in
atp_calculate_abs() can be used, possibly after rescaling.
I already thought about this, one problem is that the sensors do not
report the pressure but only the amount of surface touched. A person
with thick fingers will always generate higher pressures then one with
thin ones, no matter how hard they push on the touchpad.
I don't think this value is reliable enough to be reported to the
userspace as ABS_PRESSURE...
Anyway, here is the updated patch:
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
Documentation/input/appletouch.txt | 83 ++
drivers/usb/input/Kconfig | 19 +
drivers/usb/input/Makefile |1
drivers/usb/input/appletouch.c | 509
+
4 files changed, 612 insertions(+)
Index: linux-2.6.git/drivers/usb/input/Makefile
===
--- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-11
09:46:57.0 +0200
+++ linux-2.6.git/drivers/usb/input/Makefile2005-07-11
09:48:23.0 +0200
@@ -39,3 +39,4 @@
obj-$(CONFIG_USB_WACOM)+= wacom.o
obj-$(CONFIG_USB_ACECAD) += acecad.o
obj-$(CONFIG_USB_XPAD) += xpad.o
+obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o
Index: linux-2.6.git/drivers/usb/input/Kconfig
===
--- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-11
09:46:57.0 +0200
+++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-11
09:48:23.0 +0200
@@ -259,3 +259,22 @@
To compile this driver as a module, choose M here: the module will
be
called ati_remote.
+config USB_APPLETOUCH
+ tristate Apple USB Touchpad support
+ depends on USB INPUT
+ ---help---
+ Say Y here if you want to use an Apple USB Touchpad.
+
+ These are the touchpads that can be found on post-February 2005
+ Apple Powerbooks (prior models have a Synaptics touchpad connected
+ to the ADB bus).
+
+ This driver provides a basic mouse driver but can be interfaced
+ with the synaptics X11 driver to provide acceleration and
+ scrolling in X11.
+
+ For further information, see
Re: [PATCH] Apple USB Touchpad driver (new)
On Mon, Jul 11, 2005 at 03:52:44AM -0700, Andrew Morton wrote: Stelian Pop [EMAIL PROTECTED] wrote: Anyway, here is the updated patch: Signed-off-by: Stelian Pop [EMAIL PROTECTED] Documentation/input/appletouch.txt | 83 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 509 + Badly wordwrapped. Oops, bad Evolution (even if I did use insert-text file for the patch). Going back to mutt. Sorry about this. Changelog: * CodingStyle fixes * open counter replaced by a binary flag * udev hacks are no longer necessary with a patched synaptics, update the documentation Signed-off-by: Stelian Pop [EMAIL PROTECTED] Documentation/input/appletouch.txt | 83 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 509 + 4 files changed, 612 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-11 09:48:23.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-11 09:48:23.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate Apple USB Touchpad support + depends on USB INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + file:Documentation/input/appletouch.txt. + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-11 11:57:41.0 +0200 @@ -0,0 +1,83 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop [EMAIL PROTECTED] + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation. + + Section InputDevice + Identifier Synaptics Touchpad + Driver synaptics + Option SendCoreEventstrue + Option Device/dev/input/mice + Option Protocol auto-dev + Option LeftEdge 0 + Option RightEdge 850 + Option TopEdge 0 + Option
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 13:00 +0200, Vojtech Pavlik a écrit : On Mon, Jul 11, 2005 at 12:39:31PM +0200, Stelian Pop wrote: Using a function like return (x_old * 3 + x) / 4; eliminates the need for a FIFO, and has similar (if not better) properties to floating average, because its coefficients are [ .25 .18 .14 .10 ... ]. Agreed. Except that this does not work well enough. I guess the quick motion compensation in input bites you. The above equation should do even more smoothing than regular 4-point floating average. Possible. The 'fuzz' parameter in input core serves too many usages ihmo. Let me try removing the quick motion compensation and see... I already thought about this, one problem is that the sensors do not report the pressure but only the amount of surface touched. A person with thick fingers will always generate higher pressures then one with thin ones, no matter how hard they push on the touchpad. That's what all other touchpads do. I thought the hardware is capable of calculating real pressure... I don't think this value is reliable enough to be reported to the userspace as ABS_PRESSURE... I believe it'd still be more useful than a two-value (0 and 100) output. Ok, I'll do it. + /* +* in the future, we could add here code to search for +* a second finger... +* for now, scrolling using the synaptics X driver is +* much more simpler to achieve. +*/ This could be quite useful, too, for right and middle button taps (2 and 3 fingers) - since the Macs lack these buttons. Indeed. But this can be a later improvement, let's make one finger work for now :) Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 13:21 +0200, Vojtech Pavlik a écrit : On Mon, Jul 11, 2005 at 01:08:35PM +0200, Stelian Pop wrote: Possible. The 'fuzz' parameter in input core serves too many usages ihmo. Let me try removing the quick motion compensation and see... It was designed for joysticks and works very well for them. Usefulness for other device types may vary. And I'll gladly accept patches to improve it. Ok, I understand now what is happenning, but I'm not sure how to solve the problem. As I suspected, it is caused by 'fuzz' being a bit abused by the input core. The fuzz parameter in the input core is used today to say: * any change in the -fuzz/2 / +fuzz/2 range is ignored * any change in the -fuzz / +fuzz range is smoothed using x_old * 3 + x) / 4; * any change in the -fuzz*2 / +fuzz/2 range is smoothed using x_old +x) / 2; My driver needs to ignore changes in the -8 / +8 range (that's why I set FUZZ to 16 in the first place), but it needs to smooth the movement when much larger changes occur (I would need to set FUZZ to 64 for smoothing to work correctly here). How to make it work ? Obviously I could implement either fuzz elimination or smoothing in the driver, and leave the other transformation to the input core (today it is the smoothing which is in the driver, but doing it the other way around would result in much less code). The other (proper ?) solution would be to change the input core and separate fuzz and smoothing. This would however require an API addition, and I'm not sure you want to do that. If you do, I could work on a patch implementing an inputdev-abssmooth[] table, etc). I thought the hardware is capable of calculating real pressure... Since the sensor is just a multi-layer PCB with a clever trace layout, it can't. I don't think this value is reliable enough to be reported to the userspace as ABS_PRESSURE... I believe it'd still be more useful than a two-value (0 and 100) output. Ok, I'll do it. Thanks. Should I wait for that or apply the patch you just sent? Well, it depends on what we do with smoothing. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 14:47 +0200, Stelian Pop a écrit : How to make it work ? Obviously I could implement either fuzz elimination or smoothing in the driver, and leave the other transformation to the input core (today it is the smoothing which is in the driver, but doing it the other way around would result in much less code). And of course it cannot be done without modifying input core in order to prevent it throwing away the samples. The only way to manage the current situation is to implement smoothing in the driver itself (but I used the same algorithm as in the input core, thus removing the unneeded history) I don't think this value is reliable enough to be reported to the userspace as ABS_PRESSURE... I believe it'd still be more useful than a two-value (0 and 100) output. Ok, I'll do it. Implemented too. Here is the latest incarnation of the patch, please apply this one. If Vojtech decides that it makes sense to modify the input core in order to separate fuzz and smoothing, then the driver could be simplified a bit more. Thanks, Stelian. Changes: * report ABS_PRESSURE events * simplify smoothing by using the same technique as the input core eliminating the need for a FIFO. Signed-off-by: Stelian Pop [EMAIL PROTECTED] Documentation/input/appletouch.txt | 83 ++ drivers/usb/input/Kconfig | 19 + drivers/usb/input/Makefile |1 drivers/usb/input/appletouch.c | 480 + 4 files changed, 583 insertions(+) Index: linux-2.6.git/drivers/usb/input/Makefile === --- linux-2.6.git.orig/drivers/usb/input/Makefile 2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Makefile2005-07-11 09:48:23.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6.git/drivers/usb/input/Kconfig === --- linux-2.6.git.orig/drivers/usb/input/Kconfig2005-07-11 09:46:57.0 +0200 +++ linux-2.6.git/drivers/usb/input/Kconfig 2005-07-11 09:48:23.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate Apple USB Touchpad support + depends on USB INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + file:Documentation/input/appletouch.txt. + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6.git/Documentation/input/appletouch.txt2005-07-11 15:02:51.0 +0200 @@ -0,0 +1,83 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop [EMAIL PROTECTED] + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation
Re: [PATCH] Apple USB Touchpad driver (new)
Le lundi 11 juillet 2005 à 16:44 -0400, Lee Revell a écrit : On Mon, 2005-07-11 at 13:04 +0200, Stelian Pop wrote: Oops, bad Evolution (even if I did use insert-text file for the patch). Going back to mutt. Sorry about this. There's no need to go back to mutt, Evolution is not broken. Before doing 'Insert-Text File', you just have to change the text style at the insertion point from 'Normal' to 'Preformat' to avoid word-wrapping the patch. Indeed, Alexander Nyberg already pointed this to me in private. Thanks. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT tree broken? (rsync depreciated)
[sorry Ed for the duplicate...] Le vendredi 08 juillet 2005 à 07:28 -0400, Ed Tomlinson a écrit : > Hi, > > I resync(ed) cg and rebuild this morning and it worked fine. > > On another tack. Updating the kernel gave a message that rsync is depreciated and > will soon be turned off. How should we be updating git/cg trees now? After resyncing cogito to the latest version (which incorporates the 'pack' changes, which were causing the failure), it does indeed work again, when using rsync. However, it still fails when using http. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
On Fri, Jul 08, 2005 at 01:18:01PM +0200, Johannes Berg wrote: > Hi all, > > Nice to see this going into the kernel :) > > > This is a driver for the USB touchpad which can be found on > > post-February 2005 Apple PowerBooks (PowerBook5,6). > > This is not perfectly correct, the PowerBook5,6 is afaik only the 15" > model, the 12" and 17" have other numbers. Maybe you should just leave > that out, likewise in the code/Kconfig file. Indeed, corrected. > > +/* > > + * number of sensors. Note that only 16 of the 26 x sensors are used on > > + * 12" and 15" Powerbooks. > > + */ > > I think that is misleading, those sensors don't even exist on 12" and > 15" powerbooks. Maybe it should say 'Note that only 16 instead of 26 > sensors exist on 12" and 15" models' Sure, I clarified a bit that sentence. Updated patch follows. Thanks. Stelian. Index: linux-2.6-trunk.git/drivers/usb/input/Makefile === --- linux-2.6-trunk.git.orig/drivers/usb/input/Makefile 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Makefile 2005-07-08 11:10:29.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6-trunk.git/drivers/usb/input/Kconfig === --- linux-2.6-trunk.git.orig/drivers/usb/input/Kconfig 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Kconfig 2005-07-08 14:05:15.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate "Apple USB Touchpad support" + depends on USB && INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + . + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6-trunk.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-trunk.git/Documentation/input/appletouch.txt 2005-07-08 11:15:03.00000 +0200 @@ -0,0 +1,120 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]> + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation. + + Section "InputDevice" + Identifier "Synaptics Touchpad" + Driver "synaptics" + Option "SendCoreEvents""true" + Option "Device""/dev/input/mice" + Option "Protocol" "auto-dev" + Option "LeftEdge" "0" + Option "RightEdge"
Re: GIT tree broken?
Le vendredi 08 juillet 2005 à 03:18 -0700, Andrew Morton a écrit : > Maybe post-0.12 broke. Try the 0.12 release. Did try that but it does not solve the problem: deep-space-9:~/kernel/git 41 > cg-version cogito-0.12 deep-space-9:~/kernel/git 42 > cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git defaulting to local storage area 12:26:25 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master [41/41] -> "refs/heads/origin" [1] progress: 2 objects, 981 bytes error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 (http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166) corrupt Cannot obtain needed blob 2a7e338ec2fc6aac461a11fe8049799e65639166 while processing commit . cg-pull: objects pull failed cg-init: pull failed If I manually try to get http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166 I get a 404 in return. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Apple USB Touchpad driver (new)
Hi, This is a driver for the USB touchpad which can be found on post-February 2005 Apple PowerBooks (PowerBook5,6). This driver is derived from Johannes Berg's appletrackpad driver [1], but it has been improved in some areas: * appletouch is a full kernel driver, no userspace program is necessary * appletouch can be interfaced with the synaptics X11 driver[2], in order to have touchpad acceleration, scrolling, etc. This driver has been tested by the readers of the 'debian-powerpc' mailing list for a few weeks now and I believe it is now ready for inclusion into the mainline kernel. Credits go to Johannes Berg for reverse-engineering the touchpad protocol, Frank Arnold for further improvements, and Alex Harper for some additional information about the inner workings of the touchpad sensors. Please apply. Stelian. [1]: http://johannes.sipsolutions.net/PowerBook/touchpad/ [2]: http://web.telia.com/~u89404340/touchpad/index.html Index: linux-2.6-trunk.git/drivers/usb/input/Makefile === --- linux-2.6-trunk.git.orig/drivers/usb/input/Makefile 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Makefile 2005-07-08 11:10:29.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6-trunk.git/drivers/usb/input/Kconfig === --- linux-2.6-trunk.git.orig/drivers/usb/input/Kconfig 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Kconfig 2005-07-08 11:14:48.0 +0200 @@ -259,3 +259,21 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate "Apple USB Touchpad support" + depends on USB && INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (PowerBook5,6). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + . + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6-trunk.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-trunk.git/Documentation/input/appletouch.txt 2005-07-08 11:15:03.0 +0200 @@ -0,0 +1,120 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]> + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation. + + Section "InputDevice" + Identifier "Synaptics Touchpad" + Driver "synaptics" + Option "SendCoreEvents""true" + Option "Device""/dev/input/mice" + Option "Protocol" "auto-dev" + Option "LeftEdge" "0" + Option "RightEdge" "850" + Option "TopEdge"
Re: GIT tree broken?
Le vendredi 08 juillet 2005 à 12:30 +0300, Meelis Roos a écrit : > I'm trying to sync with > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > with cogito cg-update (cogito 0.11.3+20050610-1 Debian package) and it > fails with the following error: > > Applying changes... > error: cannot map sha1 file 043d051615aa5da09a7e44f1edbb69798458e067 > error: Could not read 043d051615aa5da09a7e44f1edbb69798458e067 > cg-merge: unable to automatically determine merge base I see this too, with the latest cogito git tree, reproductible even in a fresh environment: $ rm -rf linux-2.6.git $ cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git defaulting to local storage area 11:57:48 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master[41/41] -> "refs/heads/origin" [1] progress: 2 objects, 981 bytes error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 (http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166) corrupt Cannot obtain needed blob 2a7e338ec2fc6aac461a11fe8049799e65639166 while processing commit . cg-pull: objects pull failed cg-init: pull failed Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GIT tree broken?
Le vendredi 08 juillet 2005 à 12:30 +0300, Meelis Roos a écrit : I'm trying to sync with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git with cogito cg-update (cogito 0.11.3+20050610-1 Debian package) and it fails with the following error: Applying changes... error: cannot map sha1 file 043d051615aa5da09a7e44f1edbb69798458e067 error: Could not read 043d051615aa5da09a7e44f1edbb69798458e067 cg-merge: unable to automatically determine merge base I see this too, with the latest cogito git tree, reproductible even in a fresh environment: $ rm -rf linux-2.6.git $ cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git defaulting to local storage area 11:57:48 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master[41/41] - refs/heads/origin [1] progress: 2 objects, 981 bytes error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 (http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166) corrupt Cannot obtain needed blob 2a7e338ec2fc6aac461a11fe8049799e65639166 while processing commit . cg-pull: objects pull failed cg-init: pull failed Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Apple USB Touchpad driver (new)
Hi, This is a driver for the USB touchpad which can be found on post-February 2005 Apple PowerBooks (PowerBook5,6). This driver is derived from Johannes Berg's appletrackpad driver [1], but it has been improved in some areas: * appletouch is a full kernel driver, no userspace program is necessary * appletouch can be interfaced with the synaptics X11 driver[2], in order to have touchpad acceleration, scrolling, etc. This driver has been tested by the readers of the 'debian-powerpc' mailing list for a few weeks now and I believe it is now ready for inclusion into the mainline kernel. Credits go to Johannes Berg for reverse-engineering the touchpad protocol, Frank Arnold for further improvements, and Alex Harper for some additional information about the inner workings of the touchpad sensors. Please apply. Stelian. [1]: http://johannes.sipsolutions.net/PowerBook/touchpad/ [2]: http://web.telia.com/~u89404340/touchpad/index.html Index: linux-2.6-trunk.git/drivers/usb/input/Makefile === --- linux-2.6-trunk.git.orig/drivers/usb/input/Makefile 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Makefile 2005-07-08 11:10:29.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6-trunk.git/drivers/usb/input/Kconfig === --- linux-2.6-trunk.git.orig/drivers/usb/input/Kconfig 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Kconfig 2005-07-08 11:14:48.0 +0200 @@ -259,3 +259,21 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate Apple USB Touchpad support + depends on USB INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (PowerBook5,6). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + file:Documentation/input/appletouch.txt. + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6-trunk.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-trunk.git/Documentation/input/appletouch.txt 2005-07-08 11:15:03.0 +0200 @@ -0,0 +1,120 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop [EMAIL PROTECTED] + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation. + + Section InputDevice + Identifier Synaptics Touchpad + Driver synaptics + Option SendCoreEventstrue + Option Device/dev/input/mice + Option Protocol auto-dev + Option LeftEdge 0 + Option RightEdge 850 + Option TopEdge 0 + Option BottomEdge645 + Option MinSpeed 0.4 + Option
Re: GIT tree broken?
Le vendredi 08 juillet 2005 à 03:18 -0700, Andrew Morton a écrit : Maybe post-0.12 broke. Try the 0.12 release. Did try that but it does not solve the problem: deep-space-9:~/kernel/git 41 cg-version cogito-0.12 deep-space-9:~/kernel/git 42 cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git defaulting to local storage area 12:26:25 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master [41/41] - refs/heads/origin [1] progress: 2 objects, 981 bytes error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 (http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166) corrupt Cannot obtain needed blob 2a7e338ec2fc6aac461a11fe8049799e65639166 while processing commit . cg-pull: objects pull failed cg-init: pull failed If I manually try to get http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166 I get a 404 in return. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Apple USB Touchpad driver (new)
On Fri, Jul 08, 2005 at 01:18:01PM +0200, Johannes Berg wrote: Hi all, Nice to see this going into the kernel :) This is a driver for the USB touchpad which can be found on post-February 2005 Apple PowerBooks (PowerBook5,6). This is not perfectly correct, the PowerBook5,6 is afaik only the 15 model, the 12 and 17 have other numbers. Maybe you should just leave that out, likewise in the code/Kconfig file. Indeed, corrected. +/* + * number of sensors. Note that only 16 of the 26 x sensors are used on + * 12 and 15 Powerbooks. + */ I think that is misleading, those sensors don't even exist on 12 and 15 powerbooks. Maybe it should say 'Note that only 16 instead of 26 sensors exist on 12 and 15 models' Sure, I clarified a bit that sentence. Updated patch follows. Thanks. Stelian. Index: linux-2.6-trunk.git/drivers/usb/input/Makefile === --- linux-2.6-trunk.git.orig/drivers/usb/input/Makefile 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Makefile 2005-07-08 11:10:29.0 +0200 @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_WACOM)+= wacom.o obj-$(CONFIG_USB_ACECAD) += acecad.o obj-$(CONFIG_USB_XPAD) += xpad.o +obj-$(CONFIG_USB_APPLETOUCH) += appletouch.o Index: linux-2.6-trunk.git/drivers/usb/input/Kconfig === --- linux-2.6-trunk.git.orig/drivers/usb/input/Kconfig 2005-06-28 10:25:42.0 +0200 +++ linux-2.6-trunk.git/drivers/usb/input/Kconfig 2005-07-08 14:05:15.0 +0200 @@ -259,3 +259,22 @@ To compile this driver as a module, choose M here: the module will be called ati_remote. +config USB_APPLETOUCH + tristate Apple USB Touchpad support + depends on USB INPUT + ---help--- + Say Y here if you want to use an Apple USB Touchpad. + + These are the touchpads that can be found on post-February 2005 + Apple Powerbooks (prior models have a Synaptics touchpad connected + to the ADB bus). + + This driver provides a basic mouse driver but can be interfaced + with the synaptics X11 driver to provide acceleration and + scrolling in X11. + + For further information, see + file:Documentation/input/appletouch.txt. + + To compile this driver as a module, choose M here: the + module will be called appletouch. Index: linux-2.6-trunk.git/Documentation/input/appletouch.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-trunk.git/Documentation/input/appletouch.txt 2005-07-08 11:15:03.0 +0200 @@ -0,0 +1,120 @@ +Apple Touchpad Driver (appletouch) +-- + Copyright (C) 2005 Stelian Pop [EMAIL PROTECTED] + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +-- + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling etc. In +order to do this, make sure you're using a recent version of the synaptics +driver (tested with 0.14.2, available from [2]), and configure a new input +device in your X11 configuration file (take a look below for an example). For +additional configuration, see the synaptics driver documentation. + + Section InputDevice + Identifier Synaptics Touchpad + Driver synaptics + Option SendCoreEventstrue + Option Device/dev/input/mice + Option Protocol auto-dev + Option LeftEdge 0 + Option RightEdge 850 + Option TopEdge 0 + Option BottomEdge645 + Option MinSpeed 0.4 + Option MaxSpeed 1 + Option AccelFactor 0.02
Re: GIT tree broken? (rsync depreciated)
[sorry Ed for the duplicate...] Le vendredi 08 juillet 2005 à 07:28 -0400, Ed Tomlinson a écrit : Hi, I resync(ed) cg and rebuild this morning and it worked fine. On another tack. Updating the kernel gave a message that rsync is depreciated and will soon be turned off. How should we be updating git/cg trees now? After resyncing cogito to the latest version (which incorporates the 'pack' changes, which were causing the failure), it does indeed work again, when using rsync. However, it still fails when using http. Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD64 Machine hardlocks when using memset
On Thu, Mar 31, 2005 at 12:04:59AM +0200, Philip Lawatsch wrote: > I do have a very strange problem: > > If I memset a ~1meg buffer some thousand times (in the userspace) it > will hardlock my machine. > > I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9, > 2.6.11). I've tried it both using a 32 bit kernel and a 64 bit kernel. > When running on the 32 bit kernel the machine hardlocks after about > 15000 iterations, on a 64 bit kernel the machine hardlocks after about > 5000 (the 64 bit system has nearly no background jobs running). > > I've been running memcheck for several hours now but nothing did show up. > > > I've got an Asus A8N-SLI board with 2 gigs of memory and an AMD 3500+ CPU. > > The 64 bit kernel was compiled using gcc 3.4.3 and the 32 bit kernel > using 3.3.5. [...] > powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e) > powernow-k8:0 : fid 0xe (2200 MHz), vid 0x6 (1400 mV) > powernow-k8:1 : fid 0xc (2000 MHz), vid 0x8 (1350 mV) > powernow-k8:2 : fid 0xa (1800 MHz), vid 0xa (1300 mV) > powernow-k8:3 : fid 0x2 (1000 MHz), vid 0x12 (1100 mV) > cpu_init done, current fid 0xe, vid 0x6 Just a thought: does deactivating cpufreq change anything ? I haven't tested yet your program, but on my Asus K8NE-Deluxe very strange things happen if cpufreq/powernow is activated *and* the cpu frequency is changed... Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD64 Machine hardlocks when using memset
On Thu, Mar 31, 2005 at 12:04:59AM +0200, Philip Lawatsch wrote: I do have a very strange problem: If I memset a ~1meg buffer some thousand times (in the userspace) it will hardlock my machine. I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9, 2.6.11). I've tried it both using a 32 bit kernel and a 64 bit kernel. When running on the 32 bit kernel the machine hardlocks after about 15000 iterations, on a 64 bit kernel the machine hardlocks after about 5000 (the 64 bit system has nearly no background jobs running). I've been running memcheck for several hours now but nothing did show up. I've got an Asus A8N-SLI board with 2 gigs of memory and an AMD 3500+ CPU. The 64 bit kernel was compiled using gcc 3.4.3 and the 32 bit kernel using 3.3.5. [...] powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e) powernow-k8:0 : fid 0xe (2200 MHz), vid 0x6 (1400 mV) powernow-k8:1 : fid 0xc (2000 MHz), vid 0x8 (1350 mV) powernow-k8:2 : fid 0xa (1800 MHz), vid 0xa (1300 mV) powernow-k8:3 : fid 0x2 (1000 MHz), vid 0x12 (1100 mV) cpu_init done, current fid 0xe, vid 0x6 Just a thought: does deactivating cpufreq change anything ? I haven't tested yet your program, but on my Asus K8NE-Deluxe very strange things happen if cpufreq/powernow is activated *and* the cpu frequency is changed... Stelian. -- Stelian Pop [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BKCVS broken ?
On Fri, Mar 18, 2005 at 08:38:51PM +0530, Hong Kong Phoey wrote: > IMHO, BKCVS is just fine, what's broken is your head. Yup, that's what I said, that cvs HEAD is broken... :) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BKCVS broken ?
On Fri, Mar 18, 2005 at 06:13:45AM -0800, Larry McVoy wrote:
> On Fri, Mar 18, 2005 at 10:00:49AM +0100, Stelian Pop wrote:
> > On Thu, Mar 17, 2005 at 10:38:53PM -0800, Larry McVoy wrote:
> >
> > > Hey, it's open source, I'm hoping that people will take that code and
> > > evolve it do whatever they need. We're willing to do what we can on
> > > this end if people need protocol changes to support new features,
> > > time permitting. Think of that code as a prototype. It's really
> > > simple, you can hack it trivially.
> >
> >
> > if (strncmp("bk://", p, 5)) return (1);
> >
> >
> > Any chance this could be made to work over http ?
>
> I don't see why not. It will take some hacking though. Can you live
> without it for a bit or is it urgent?
It's not urgent at all...
Thanks.
Stelian.
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
