[gentoo-user] [~amd64] Keyboard stops working several times/day

[gentoo-user] [~amd64] Keyboard stops working several times/day

[walt]

I've been seeing this keyboard problem for the past few weeks:  after
running some command from a bash prompt (haven't tried zsh yet) the
keyboard stops working.  Almost like somebody unplugged the keyboard
from its usb port (except that the LED on the keyboard stays lit so I
know the power is still on).

There are no error messages in journalctl or in /var/log/Xorg.0.log

I don't know how to change to a console without using a ctrl-alt-Fn
keystroke from the keyboard (anyone know if it's possible?).

When I unplug the keyboard from the usb port I can see the kernel
recognize the unplug event, which makes me think that it's not a
kernel/usb bug or a broken wire in the keyboard cable.

When I re-plug the keyboard into a usb port the keyboard immediately
starts working normally again until the next time I happen to trigger
the problem by running some black-magical command from a command
prompt.  There is no particular command that causes it--it can be any
arbitrary command AFAICT.

Just one weird example:  I can be typing a URL in a web browser window
when a bash command finishes running in a terminal window and the
keyboard stops working in the middle of my typing :(

Any debugging suggestions would be most welcome.

Re: [gentoo-user] [~amd64] Keyboard stops working several times/day

[Alan McKinnon]

On 16/08/2015 18:45, walt wrote:
> I've been seeing this keyboard problem for the past few weeks:  after
> running some command from a bash prompt (haven't tried zsh yet) the
> keyboard stops working.  Almost like somebody unplugged the keyboard
> from its usb port (except that the LED on the keyboard stays lit so I
> know the power is still on).
> 
> There are no error messages in journalctl or in /var/log/Xorg.0.log
> 
> I don't know how to change to a console without using a ctrl-alt-Fn
> keystroke from the keyboard (anyone know if it's possible?).
> 
> When I unplug the keyboard from the usb port I can see the kernel
> recognize the unplug event, which makes me think that it's not a
> kernel/usb bug or a broken wire in the keyboard cable.
> 
> When I re-plug the keyboard into a usb port the keyboard immediately
> starts working normally again until the next time I happen to trigger
> the problem by running some black-magical command from a command
> prompt.  There is no particular command that causes it--it can be any
> arbitrary command AFAICT.
> 
> Just one weird example:  I can be typing a URL in a web browser window
> when a bash command finishes running in a terminal window and the
> keyboard stops working in the middle of my typing :(
> 
> Any debugging suggestions would be most welcome.


First step (more to half the problem space than anything else):

Does the same happen if you use another keyboard?


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Sun, 16 Aug 2015 18:58:27 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 16/08/2015 18:45, walt wrote:
> > I've been seeing this keyboard problem for the past few weeks:
> > after running some command from a bash prompt (haven't tried zsh
> > yet) the keyboard stops working.  Almost like somebody unplugged
> > the keyboard from its usb port (except that the LED on the keyboard
> > stays lit so I know the power is still on).
> > 
> > There are no error messages in journalctl or in /var/log/Xorg.0.log
> > 
> > I don't know how to change to a console without using a ctrl-alt-Fn
> > keystroke from the keyboard (anyone know if it's possible?).
> > 
> > When I unplug the keyboard from the usb port I can see the kernel
> > recognize the unplug event, which makes me think that it's not a
> > kernel/usb bug or a broken wire in the keyboard cable.
> > 
> > When I re-plug the keyboard into a usb port the keyboard immediately
> > starts working normally again until the next time I happen to
> > trigger the problem by running some black-magical command from a
> > command prompt.  There is no particular command that causes it--it
> > can be any arbitrary command AFAICT.
> > 
> > Just one weird example:  I can be typing a URL in a web browser
> > window when a bash command finishes running in a terminal window
> > and the keyboard stops working in the middle of my typing :(
> > 
> > Any debugging suggestions would be most welcome.  
> 
> 
> First step (more to half the problem space than anything else):
> 
> Does the same happen if you use another keyboard?

I agree with your assessment -- and I will buy another usb keyboard
tomorrow because I'm using the only one I have and this machine has no
ps/2 ports.  Never thought I'd miss the ps/2 ports til now :)

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Alan McKinnon]

On 16/08/2015 21:42, walt wrote:
> On Sun, 16 Aug 2015 18:58:27 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> On 16/08/2015 18:45, walt wrote:
>>> I've been seeing this keyboard problem for the past few weeks:
>>> after running some command from a bash prompt (haven't tried zsh
>>> yet) the keyboard stops working.  Almost like somebody unplugged
>>> the keyboard from its usb port (except that the LED on the keyboard
>>> stays lit so I know the power is still on).
>>>
>>> There are no error messages in journalctl or in /var/log/Xorg.0.log
>>>
>>> I don't know how to change to a console without using a ctrl-alt-Fn
>>> keystroke from the keyboard (anyone know if it's possible?).
>>>
>>> When I unplug the keyboard from the usb port I can see the kernel
>>> recognize the unplug event, which makes me think that it's not a
>>> kernel/usb bug or a broken wire in the keyboard cable.
>>>
>>> When I re-plug the keyboard into a usb port the keyboard immediately
>>> starts working normally again until the next time I happen to
>>> trigger the problem by running some black-magical command from a
>>> command prompt.  There is no particular command that causes it--it
>>> can be any arbitrary command AFAICT.
>>>
>>> Just one weird example:  I can be typing a URL in a web browser
>>> window when a bash command finishes running in a terminal window
>>> and the keyboard stops working in the middle of my typing :(
>>>
>>> Any debugging suggestions would be most welcome.  
>>
>>
>> First step (more to half the problem space than anything else):
>>
>> Does the same happen if you use another keyboard?
> 
> I agree with your assessment -- and I will buy another usb keyboard
> tomorrow because I'm using the only one I have and this machine has no
> ps/2 ports.  Never thought I'd miss the ps/2 ports til now :)

I kind of assumed you'd have lots of spare keyboards lying around and
had already done the test :-)

I myself have 4 spares lying around my home study, all functional, and
I'm totally at a loss to explain why so many!

Anyway, back on topic. I recall something similar happening to me,
perhaps a year ago or longer. I tried to debug it and gave up, then one
day it was no longer happening. I assumed it was a fixed kernel bug then
promptly forgot all about it.

While you are waiting on a new keyboard, do you have the same bug on
different kernels?


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Sun, 16 Aug 2015 21:48:04 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 16/08/2015 21:42, walt wrote:
> > On Sun, 16 Aug 2015 18:58:27 +0200
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >   
> >> On 16/08/2015 18:45, walt wrote:  
> >>> I've been seeing this keyboard problem for the past few weeks:
> >>> after running some command from a bash prompt (haven't tried zsh
> >>> yet) the keyboard stops working.  Almost like somebody unplugged
> >>> the keyboard from its usb port (except that the LED on the
> >>> keyboard stays lit so I know the power is still on).
> >>>
> >>> There are no error messages in journalctl or
> >>> in /var/log/Xorg.0.log
> >>>
> >>> I don't know how to change to a console without using a
> >>> ctrl-alt-Fn keystroke from the keyboard (anyone know if it's
> >>> possible?).
> >>>
> >>> When I unplug the keyboard from the usb port I can see the kernel
> >>> recognize the unplug event, which makes me think that it's not a
> >>> kernel/usb bug or a broken wire in the keyboard cable.
> >>>
> >>> When I re-plug the keyboard into a usb port the keyboard
> >>> immediately starts working normally again until the next time I
> >>> happen to trigger the problem by running some black-magical
> >>> command from a command prompt.  There is no particular command
> >>> that causes it--it can be any arbitrary command AFAICT.
> >>>
> >>> Just one weird example:  I can be typing a URL in a web browser
> >>> window when a bash command finishes running in a terminal window
> >>> and the keyboard stops working in the middle of my typing :(
> >>>
> >>> Any debugging suggestions would be most welcome.    
> >>
> >>
> >> First step (more to half the problem space than anything else):
> >>
> >> Does the same happen if you use another keyboard?  
> > 
> > I agree with your assessment -- and I will buy another usb keyboard
> > tomorrow because I'm using the only one I have and this machine has
> > no ps/2 ports.  Never thought I'd miss the ps/2 ports til now :)  
> 
> I kind of assumed you'd have lots of spare keyboards lying around and
> had already done the test :-)

I do have spares, all ps/2 :-(

> I recall something similar happening to me,
> perhaps a year ago or longer. I tried to debug it and gave up, then
> one day it was no longer happening. I assumed it was a fixed kernel
> bug then promptly forgot all about it.
> 
> While you are waiting on a new keyboard, do you have the same bug on
> different kernels?

Affirmative, and thereby hangs yet another woeful tale.  I've been
running the gentoo-sources-3.14.xx series forever because I wearied of
spending so many hours debugging unstable kernels.

This morning I decided to take a giant leap forward all the way to
3.18.19 (BTW 3.18.20 is already on kernel.org) because, surely, I
wouldn't need to debug a kernel as old as that, right?

Wrong.  Linus and friends have been marking lots of existing kernel
symbols with the SYMBOL_EXPORT_GNU macro, which was designed to block
the loading of any kernel module not explicitly licensed as GNU
software.  (see output of modinfo)

x11-drivers/ati-drivers installs a proprietary binary blob (as does
nvidia-drivers) so the linker refused even to link the kernel module
into a .ko file, nevermind the kernel actually loading the module at
runtime.

The remedy for ati-drivers is well-hidden in a comment in a gentoo bug
report that I found at oh-dark-hundred hours this morning.  Only two
hours later I got the module installed and loaded :)

But yes, kernel 3.18.19 still has my same keyboard halting problem, so
I'm back to 3.14.50 until the ati-drivers package is patched.  I'm sure
gentoo-sources-3.18.20 will be available almost immediately and I'm not
going through that hell again.

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Dale]

walt wrote:
> Affirmative, and thereby hangs yet another woeful tale. I've been
> running the gentoo-sources-3.14.xx series forever because I wearied of
> spending so many hours debugging unstable kernels. This morning I
> decided to take a giant leap forward all the way to 3.18.19 (BTW
> 3.18.20 is already on kernel.org) because, surely, I wouldn't need to
> debug a kernel as old as that, right? Wrong. Linus and friends have
> been marking lots of existing kernel symbols with the
> SYMBOL_EXPORT_GNU macro, which was designed to block the loading of
> any kernel module not explicitly licensed as GNU software. (see output
> of modinfo) x11-drivers/ati-drivers installs a proprietary binary blob
> (as does nvidia-drivers) so the linker refused even to link the kernel
> module into a .ko file, nevermind the kernel actually loading the
> module at runtime. The remedy for ati-drivers is well-hidden in a
> comment in a gentoo bug report that I found at oh-dark-hundred hours
> this morning. Only two hours later I got the module installed and
> loaded :) But yes, kernel 3.18.19 still has my same keyboard halting
> problem, so I'm back to 3.14.50 until the ati-drivers package is
> patched. I'm sure gentoo-sources-3.18.20 will be available almost
> immediately and I'm not going through that hell again. 


Interesting info.  I haven't been able to get new kernels to work
either.  I wonder if this is why.  o_O

Dale

:-)  :-) 

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Sun, 16 Aug 2015 16:34:08 -0500
Dale <rdalek1967@gmail.com> wrote:

> walt wrote:
> > Affirmative, and thereby hangs yet another woeful tale. I've been
> > running the gentoo-sources-3.14.xx series forever because I wearied
> > of spending so many hours debugging unstable kernels. This morning I
> > decided to take a giant leap forward all the way to 3.18.19 (BTW
> > 3.18.20 is already on kernel.org) because, surely, I wouldn't need
> > to debug a kernel as old as that, right? Wrong. Linus and friends
> > have been marking lots of existing kernel symbols with the
> > SYMBOL_EXPORT_GPL macro, which was designed to block the loading of
> > any kernel module not explicitly licensed as GPL software. (see
> > output of modinfo) x11-drivers/ati-drivers installs a proprietary
> > binary blob (as does nvidia-drivers) so the linker refused even to
> > link the kernel module into a .ko file, nevermind the kernel
> > actually loading the module at runtime. The remedy for ati-drivers
> > is well-hidden in a comment in a gentoo bug report that I found at
> > oh-dark-hundred hours this morning. Only two hours later I got the
> > module installed and loaded :) But yes, kernel 3.18.19 still has my
> > same keyboard halting problem, so I'm back to 3.14.50 until the
> > ati-drivers package is patched. I'm sure gentoo-sources-3.18.20
> > will be available almost immediately and I'm not going through that
> > hell again.   
> 
> 
> Interesting info.  I haven't been able to get new kernels to work
> either.  I wonder if this is why.  o_O

I've skimmed some of your threads involving initrd (maybe raid?) but I
don't participate in them because I don't use either initrd or raid so
I have nothing to offer.

If your problems are caused by non-loading kernel modules, though, it
should be easy to find out by running modinfo -l on each kernel module.

Here is the cause of my problem this morning:

#modinfo -l /lib/modules/3.18.19-gentoo/video/fglrx.ko 
Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY

BTW, I post-edited a typo I made in the text you quoted:  I typed
SYMBOL_EXPORT_GNU when I really meant SYMBOL_EXPORT_GPL.  I could have
typed SYMBOL_EXPORT_RMS because I conflate the three into one synonym :)

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Dale]

walt wrote:
> On Sun, 16 Aug 2015 16:34:08 -0500
> Dale <rdalek1967@gmail.com> wrote:
>
>> walt wrote:
>>> Affirmative, and thereby hangs yet another woeful tale. I've been
>>> running the gentoo-sources-3.14.xx series forever because I wearied
>>> of spending so many hours debugging unstable kernels. This morning I
>>> decided to take a giant leap forward all the way to 3.18.19 (BTW
>>> 3.18.20 is already on kernel.org) because, surely, I wouldn't need
>>> to debug a kernel as old as that, right? Wrong. Linus and friends
>>> have been marking lots of existing kernel symbols with the
>>> SYMBOL_EXPORT_GPL macro, which was designed to block the loading of
>>> any kernel module not explicitly licensed as GPL software. (see
>>> output of modinfo) x11-drivers/ati-drivers installs a proprietary
>>> binary blob (as does nvidia-drivers) so the linker refused even to
>>> link the kernel module into a .ko file, nevermind the kernel
>>> actually loading the module at runtime. The remedy for ati-drivers
>>> is well-hidden in a comment in a gentoo bug report that I found at
>>> oh-dark-hundred hours this morning. Only two hours later I got the
>>> module installed and loaded :) But yes, kernel 3.18.19 still has my
>>> same keyboard halting problem, so I'm back to 3.14.50 until the
>>> ati-drivers package is patched. I'm sure gentoo-sources-3.18.20
>>> will be available almost immediately and I'm not going through that
>>> hell again.   
>>
>> Interesting info.  I haven't been able to get new kernels to work
>> either.  I wonder if this is why.  o_O
> I've skimmed some of your threads involving initrd (maybe raid?) but I
> don't participate in them because I don't use either initrd or raid so
> I have nothing to offer.
>
> If your problems are caused by non-loading kernel modules, though, it
> should be easy to find out by running modinfo -l on each kernel module.
>
> Here is the cause of my problem this morning:
>
> #modinfo -l /lib/modules/3.18.19-gentoo/video/fglrx.ko 
> Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY
>
> BTW, I post-edited a typo I made in the text you quoted:  I typed
> SYMBOL_EXPORT_GNU when I really meant SYMBOL_EXPORT_GPL.  I could have
> typed SYMBOL_EXPORT_RMS because I conflate the three into one synonym :)
>
>
>
>


No RAID here, although it would likely be a good idea.  I just have /usr
on a separate partition. 

I build my kernels with everything built in.  The only module I have is
Nvidia but that is one thing that doesn't work at times.  Sometimes, it
doesn't want to boot all the way.  It doesn't even get through the
kernel loading everything up at times. 

I need to work on this some time soon.  Problem is, I rarely reboot. 
Generally, power failure is about all that will get me to
shutdown/reboot.  Recently tho, lightening has done the job.  My
neighbor got hit last week.  Their DSL went out, blew up a outside wall
plug and took out my land line, tho I rarely use it either.   They live
a quarter mile away but it sure was loud.  I'm surprised that side of
the house still had windows.  Anyway, maybe I will get around to it one
of these days.  At least 3.18.7 is working OK. 

Dale

:-)  :-) 

[gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[walt]

<entire post severely snipped for brevity>

On Mon, 17 Aug 2015 00:53:37 -0500
Dale <rdalek1967@gmail.com> wrote:

> >> walt wrote:  
> >>> Linus and friends have been marking lots of existing
> >>> kernel symbols with the SYMBOL_EXPORT_GPL macro, which was
> >>> designed to block the loading of any kernel module not explicitly
> >>> licensed as GPL software.    
 
> The only module I have
> is Nvidia but that is one thing that doesn't work at times.
> Sometimes, it doesn't want to boot all the way.  It doesn't even get
> through the kernel loading everything up at times. 

The Nvidia module is causing your problem then, because Nvidia supplies
their binary blob under their own proprietary license.

I'm using an elderly version of x11-drivers/nvidia-drivers on an
elderly machine, but when I run 'modinfo -l nvidia' I see 'NVIDIA' as
the response.  If the response isn't 'GPL' then the affected kernels
will refuse to load the module at boot time.

The kernel devs have provided a workaround for the problem, however:

You (or a gentoo dev) need to edit the source code for the problem
kernel by changing the SYMBOL_EXPORT_GPL to SYMBOL_EXPORT.

That macro appears maybe hundreds of places in the kernel sources, and
has been there for years now, but only one or two of those source files
needs to be patched, depending on which of those exported symbols is
needed by your particular binary driver (e.g. nvidia-drivers or
ati-drivers).

This whole GPL/module thing is far from new.  What's new is that the
kernel devs are slowly adding more kernel symbols to their black list.

I think the idea is to turn up the pressure very slowly on companies
like Nividia and ATI to discourage them from providing proprietary
drivers while not driving them out of the linux market completely.

Every year linux is getting stronger and the devs can afford to be
pushier with wealthy corporations who need more linux customers.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Dale]

walt wrote:
> <entire post severely snipped for brevity>
>
> On Mon, 17 Aug 2015 00:53:37 -0500
> Dale <rdalek1967@gmail.com> wrote:
>
>>>> walt wrote:  
>>>>> Linus and friends have been marking lots of existing
>>>>> kernel symbols with the SYMBOL_EXPORT_GPL macro, which was
>>>>> designed to block the loading of any kernel module not explicitly
>>>>> licensed as GPL software.    
>  
>> The only module I have
>> is Nvidia but that is one thing that doesn't work at times.
>> Sometimes, it doesn't want to boot all the way.  It doesn't even get
>> through the kernel loading everything up at times. 
> The Nvidia module is causing your problem then, because Nvidia supplies
> their binary blob under their own proprietary license.
>
> I'm using an elderly version of x11-drivers/nvidia-drivers on an
> elderly machine, but when I run 'modinfo -l nvidia' I see 'NVIDIA' as
> the response.  If the response isn't 'GPL' then the affected kernels
> will refuse to load the module at boot time.
>
> The kernel devs have provided a workaround for the problem, however:
>
> You (or a gentoo dev) need to edit the source code for the problem
> kernel by changing the SYMBOL_EXPORT_GPL to SYMBOL_EXPORT.
>
> That macro appears maybe hundreds of places in the kernel sources, and
> has been there for years now, but only one or two of those source files
> needs to be patched, depending on which of those exported symbols is
> needed by your particular binary driver (e.g. nvidia-drivers or
> ati-drivers).
>
> This whole GPL/module thing is far from new.  What's new is that the
> kernel devs are slowly adding more kernel symbols to their black list.
>
> I think the idea is to turn up the pressure very slowly on companies
> like Nividia and ATI to discourage them from providing proprietary
> drivers while not driving them out of the linux market completely.
>
> Every year linux is getting stronger and the devs can afford to be
> pushier with wealthy corporations who need more linux customers.
>
>
>
>
>


I think there is two issues but you are addressing one of them it
seems.  The other issue happens when the kernel panics and it reboots
itself.  It doesn't complete the boot process.  The one you describe
could be it tho.  On that one, I don't have a GUI.  Since I use my puter
a lot, I usually just reboot to a known working kernel and deal with it
later. 

While I think I get the idea of what the kernel devs are doing.  I also
think they should let the users send the message.  The users can start
buying ATI or other video hardware and at some point, they will either
get their ducks in a row or lose sales.  In the meantime, the users
decide what software they want to use. 

I did some searching based on the config option you gave and I'm unable
to find a way to override this myself.  It doesn't seem to be a setting
I can put in make.conf or package.use etc either.  If this is the case,
I may wish Nvidia would switch to open source but it sort of rubs me the
wrong way that someone else is making the decision and me having no way
to exercise my decision to use it anyway.   I don't care if Nvidia
doesn't show its code as long as it works and it isn't spying on me or
blowing up my house here. 

If you have any info on how to override this, I'd be glad to see it. 
Just a link or something would help. 

Thanks.

Dale

:-)  :-) 

[gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[walt]

On Tue, 18 Aug 2015 15:49:16 -0500
Dale <rdalek1967@gmail.com> wrote:

> walt wrote:
> > <entire post severely snipped for brevity>
> >
> > On Mon, 17 Aug 2015 00:53:37 -0500
> > Dale <rdalek1967@gmail.com> wrote:
> >  
> >>>> walt wrote:    
> >>>>> Linus and friends have been marking lots of existing
> >>>>> kernel symbols with the SYMBOL_EXPORT_GPL macro, which was
> >>>>> designed to block the loading of any kernel module not
> >>>>> explicitly licensed as GPL software.      
> >    
> >> The only module I have
> >> is Nvidia but that is one thing that doesn't work at times.
> >> Sometimes, it doesn't want to boot all the way.  It doesn't even
> >> get through the kernel loading everything up at times.   
> > The Nvidia module is causing your problem then, because Nvidia
> > supplies their binary blob under their own proprietary license.
> >
> > I'm using an elderly version of x11-drivers/nvidia-drivers on an
> > elderly machine, but when I run 'modinfo -l nvidia' I see 'NVIDIA'
> > as the response.  If the response isn't 'GPL' then the affected
> > kernels will refuse to load the module at boot time.
> >
> > The kernel devs have provided a workaround for the problem, however:
> >
> > You (or a gentoo dev) need to edit the source code for the problem
> > kernel by changing the SYMBOL_EXPORT_GPL to SYMBOL_EXPORT.
> >
> > That macro appears maybe hundreds of places in the kernel sources,
> > and has been there for years now, but only one or two of those
> > source files needs to be patched, depending on which of those
> > exported symbols is needed by your particular binary driver (e.g.
> > nvidia-drivers or ati-drivers).
> >
> > This whole GPL/module thing is far from new.  What's new is that the
> > kernel devs are slowly adding more kernel symbols to their black
> > list.
> >
> > I think the idea is to turn up the pressure very slowly on companies
> > like Nividia and ATI to discourage them from providing proprietary
> > drivers while not driving them out of the linux market completely.
> >
> > Every year linux is getting stronger and the devs can afford to be
> > pushier with wealthy corporations who need more linux customers.
> >
> >
> >
> >
> >  
> 
> 
> I think there is two issues but you are addressing one of them it
> seems.  The other issue happens when the kernel panics and it reboots
> itself.  It doesn't complete the boot process.  The one you describe
> could be it tho.  On that one, I don't have a GUI.  Since I use my
> puter a lot, I usually just reboot to a known working kernel and deal
> with it later. 
> 
> While I think I get the idea of what the kernel devs are doing.  I
> also think they should let the users send the message.  The users can
> start buying ATI or other video hardware and at some point, they will
> either get their ducks in a row or lose sales.  In the meantime, the
> users decide what software they want to use. 
> 
> I did some searching based on the config option you gave and I'm
> unable to find a way to override this myself.  It doesn't seem to be
> a setting I can put in make.conf or package.use etc either.  If this
> is the case, I may wish Nvidia would switch to open source but it
> sort of rubs me the wrong way that someone else is making the
> decision and me having no way to exercise my decision to use it
> anyway.   I don't care if Nvidia doesn't show its code as long as it
> works and it isn't spying on me or blowing up my house here. 
> 
> If you have any info on how to override this, I'd be glad to see it. 
> Just a link or something would help. 

This is a bug for ati-drivers, but nvidia-drivers has exactly the same
problem to solve.  Comments 7, 8, 9 sum it up pretty well:

https://bugs.gentoo.org/show_bug.cgi?id=548118

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Dale]

walt wrote:
> On Tue, 18 Aug 2015 15:49:16 -0500
> Dale <rdalek1967@gmail.com> wrote:
>
>>
>>
>> I think there is two issues but you are addressing one of them it
>> seems.  The other issue happens when the kernel panics and it reboots
>> itself.  It doesn't complete the boot process.  The one you describe
>> could be it tho.  On that one, I don't have a GUI.  Since I use my
>> puter a lot, I usually just reboot to a known working kernel and deal
>> with it later. 
>>
>> While I think I get the idea of what the kernel devs are doing.  I
>> also think they should let the users send the message.  The users can
>> start buying ATI or other video hardware and at some point, they will
>> either get their ducks in a row or lose sales.  In the meantime, the
>> users decide what software they want to use. 
>>
>> I did some searching based on the config option you gave and I'm
>> unable to find a way to override this myself.  It doesn't seem to be
>> a setting I can put in make.conf or package.use etc either.  If this
>> is the case, I may wish Nvidia would switch to open source but it
>> sort of rubs me the wrong way that someone else is making the
>> decision and me having no way to exercise my decision to use it
>> anyway.   I don't care if Nvidia doesn't show its code as long as it
>> works and it isn't spying on me or blowing up my house here. 
>>
>> If you have any info on how to override this, I'd be glad to see it. 
>> Just a link or something would help. 
> This is a bug for ati-drivers, but nvidia-drivers has exactly the same
> problem to solve.  Comments 7, 8, 9 sum it up pretty well:
>
> https://bugs.gentoo.org/show_bug.cgi?id=548118
>
>

I read through that long thing.  It seems the kernel folks are stirring
up a storm that makes the users have to jump through hoops.  Let me see
if I get this right.  The kernel devs don't want to allow a user to
install a driver that they don't approve of.  Those would include Nvidia
and ATI it would seem, at least.  So, since they don't like the drivers,
they make it so that users can't use them.  Which leaves users with two
options, three if you like to jump a lot.  Option one, don't upgrade
your kernel and use the older versions, lacking security fixes and all
that goes with it.  Option 2, do without a GUI since you don't have
video driver for your video card.  Option 3, force the drivers to build
and maybe even violate the law while doing it.  It seems based on one
post that you can't just change that code so that it will load like it
has before.  Well, at least not easily. 

Here's a clue.  Why doesn't the kernel devs let users decide what
drivers they are comfy with using?  If they don't like the drivers, then
make it so that users have to install their own just like we have for
ages but don't disable them or make them not load and work.  The kernel
devs can stop using the drivers they don't like and sit there in a
console with no GUI while the rest of us go on with life and using our
video drivers that we are happy with. 

Sounds to simple don't it?  LOL 

Dale

:-)  :-) 

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/18/2015 08:39 PM, Dale wrote:
> 
> Here's a clue.  Why doesn't the kernel devs let users decide what
> drivers they are comfy with using?  If they don't like the drivers, then
> make it so that users have to install their own just like we have for
> ages but don't disable them or make them not load and work.

A lot of people build and distribute kernels. The EXPORT_SYMBOL_GPL
thing is there to prevent those people from linking closed-source
modules against certain parts of the kernel, because the result would
not be distributable under the GPL. The legal issue is there regardless:
you can't link closed-source stuff to GPL code and then distribute the
result.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Tue, Aug 18, 2015 at 11:12 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/18/2015 08:39 PM, Dale wrote:
>>
>> Here's a clue.  Why doesn't the kernel devs let users decide what
>> drivers they are comfy with using?  If they don't like the drivers, then
>> make it so that users have to install their own just like we have for
>> ages but don't disable them or make them not load and work.
>
> A lot of people build and distribute kernels. The EXPORT_SYMBOL_GPL
> thing is there to prevent those people from linking closed-source
> modules against certain parts of the kernel, because the result would
> not be distributable under the GPL. The legal issue is there regardless:
> you can't link closed-source stuff to GPL code and then distribute the
> result.
>

I don't really buy into that argument here.

What makes nvidia.ko a derivative-work of the kernel?  It doesn't
contain any code not written by them.

I can buy into the argument that once it is loaded into memory and
linked against the kernel that the image in RAM becomes a derivative
work, but nobody is making copies of that image or redistributing it.

Take a 1950s science-fiction movie.  If you add voice-over and call it
Mystery Science Theater 3000 that is a derivative work, because it
incorporates parts of the original work.  If you put the voice-over on
separate media and call it Rifftrax it isn't a derivative work,
because it doesn't incorporate any elements of the original.  That
remains true even if it is dynamically linked to the original by
adding an instruction to unpause the recording when the movie title
appears.

The whole GPL-prevents-linking argument seems rather tenuous to me,
and as far as I'm aware it has never been upheld by a court.  It is of
course accepted as gospel in FOSS circles, but as far as I can tell it
is based on arguments that are similar to those employed by the likes
of Oracle and SCO wanting to copyright enums and APIs.

If somebody distributes a modified kernel I buy that they have to
publish the source code.  If somebody says "take your kernel image and
insert this blob of bytes at address foo" I don't see how making or
obeying that statement is illegal.  Well, a dynamic library or kernel
module is just a standardized way of doing just that.

The patch I wrote is arguably a derivative work of the kernel
(reproduced here for convenience):

diff --git a/include/linux/export.h b/include/linux/export.h
index 96e45ea..b1bc4c3 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -69,7 +69,7 @@ extern struct module __this_module;
        __EXPORT_SYMBOL(sym, "")

 #define EXPORT_SYMBOL_GPL(sym)                                 \
-       __EXPORT_SYMBOL(sym, "_gpl")
+       __EXPORT_SYMBOL(sym, "")

 #define EXPORT_SYMBOL_GPL_FUTURE(sym)                          \
        __EXPORT_SYMBOL(sym, "_gpl_future")

Now, instead of writing that suppose I instead had written this: "Edit
the file include/linux/export.h, go to line 72 and remote the text
enclosed in quotation marks, leaving an empty string."  Would that
statement be a derivative work in any way of the kernel?  That would
be like arguing that I own the rights to anything anybody says which
happens to mention my name.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 7:00:15 AM Rich Freeman wrote:
> On Tue, Aug 18, 2015 at 11:12 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> > On 08/18/2015 08:39 PM, Dale wrote:
> >>
> >> Here's a clue.  Why doesn't the kernel devs let users decide what
> >> drivers they are comfy with using?  If they don't like the drivers, then
> >> make it so that users have to install their own just like we have for
> >> ages but don't disable them or make them not load and work.
> >
> > A lot of people build and distribute kernels. The EXPORT_SYMBOL_GPL
> > thing is there to prevent those people from linking closed-source
> > modules against certain parts of the kernel, because the result would
> > not be distributable under the GPL. The legal issue is there regardless:
> > you can't link closed-source stuff to GPL code and then distribute the
> > result.
> >
> 
> I don't really buy into that argument here.
> 
> What makes nvidia.ko a derivative-work of the kernel?  It doesn't
> contain any code not written by them.
> 
> I can buy into the argument that once it is loaded into memory and
> linked against the kernel that the image in RAM becomes a derivative
> work, but nobody is making copies of that image or redistributing it.
> 
> Take a 1950s science-fiction movie.  If you add voice-over and call it
> Mystery Science Theater 3000 that is a derivative work, because it
> incorporates parts of the original work.  If you put the voice-over on
> separate media and call it Rifftrax it isn't a derivative work,
> because it doesn't incorporate any elements of the original.  That
> remains true even if it is dynamically linked to the original by
> adding an instruction to unpause the recording when the movie title
> appears.
> 
> The whole GPL-prevents-linking argument seems rather tenuous to me,
> and as far as I'm aware it has never been upheld by a court.  It is of
> course accepted as gospel in FOSS circles, but as far as I can tell it
> is based on arguments that are similar to those employed by the likes
> of Oracle and SCO wanting to copyright enums and APIs.
>
>
> If somebody distributes a modified kernel I buy that they have to
> publish the source code.  If somebody says "take your kernel image and
> insert this blob of bytes at address foo" I don't see how making or
> obeying that statement is illegal.  Well, a dynamic library or kernel
> module is just a standardized way of doing just that.

The illegal part is not loading it but distributing the blob that depends on 
the GPL exports. Vendors can modify their blobs not to depend on GPL symbols 
and distribute them. Unfortunately the result would be that proprietary driver 
vendors will have to do more reinventing of the wheel introducing bugs in the 
process.

That said, I find it hypocritical that the FSF does not condemn this practice 
since they campaign against DRM and that's exactly what this is.
 
> The patch I wrote is arguably a derivative work of the kernel
> (reproduced here for convenience):
> 
> diff --git a/include/linux/export.h b/include/linux/export.h
> index 96e45ea..b1bc4c3 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -69,7 +69,7 @@ extern struct module __this_module;
>         __EXPORT_SYMBOL(sym, "")
> 
>  #define EXPORT_SYMBOL_GPL(sym)                                 \
> -       __EXPORT_SYMBOL(sym, "_gpl")
> +       __EXPORT_SYMBOL(sym, "")
> 
>  #define EXPORT_SYMBOL_GPL_FUTURE(sym)                          \
>         __EXPORT_SYMBOL(sym, "_gpl_future")
> 
> Now, instead of writing that suppose I instead had written this: "Edit
> the file include/linux/export.h, go to line 72 and remote the text
> enclosed in quotation marks, leaving an empty string."  Would that
> statement be a derivative work in any way of the kernel?  

I don't think it matters if it is because 1) the GPL allows you to distribute 
derived works in source form, and 2) source code is protected by free speech 
as long as you didn't break the law in writing it (like reverse engineering a 
binary blob when it's license forbids it).

> That would
> be like arguing that I own the rights to anything anybody says which
> happens to mention my name.
> 
> 

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 3:06 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
>
> The illegal part is not loading it but distributing the blob that depends on
> the GPL exports.

What makes it illegal?  Quote the text of the relevant statute or
court case.  That is the issue here.  People argue that linking
creates a derivative work, and I think that at best it only creates a
derivative work after the image ends up in RAM.  The blob itself
doesn't contain any kernel code, unless you count a bunch of symbol
names.  And that is API copyrighting, which is a horrible idea (though
one the US seems to be entertaining now all the same; Murcia!).

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 05:28 PM, Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 3:06 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
>>
>> The illegal part is not loading it but distributing the blob that depends on
>> the GPL exports.
> 
> What makes it illegal?  Quote the text of the relevant statute or
> court case.

Copyright law makes everything illegal. Downloading the source and
reading it is illegal. Why wouldn't it be illegal? The copyright holders
have made it clear that you have no license to do so.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 6:09 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/19/2015 05:28 PM, Rich Freeman wrote:
>> On Wed, Aug 19, 2015 at 3:06 PM, Fernando Rodriguez
>> <frodriguez.developer@outlook.com> wrote:
>>>
>>> The illegal part is not loading it but distributing the blob that depends on
>>> the GPL exports.
>>
>> What makes it illegal?  Quote the text of the relevant statute or
>> court case.
>
> Copyright law makes everything illegal. Downloading the source and
> reading it is illegal. Why wouldn't it be illegal? The copyright holders
> have made it clear that you have no license to do so.
>

If I distribute a binary kernel module, I'm not copying anything that
I didn't write.  I'm the copyright holder of the binary kernel module.

The argument they're making is that it is a derivative work, and I see
no basis for that in the statue.

That is why I want you to actually look up the letter of the law,
because if the specific action being done isn't in the letter of the
law, then those claiming copyright have an uphill battle ahead of
them.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 06:21 PM, Rich Freeman wrote:
>>
>> Copyright law makes everything illegal. Downloading the source and
>> reading it is illegal. Why wouldn't it be illegal? The copyright holders
>> have made it clear that you have no license to do so.
>>
> 
> If I distribute a binary kernel module, I'm not copying anything that
> I didn't write.  I'm the copyright holder of the binary kernel module.
> 

Anything you can do without the kernel source code is legal, sure. But
we're talking about...

1. Downloading the kernel source (making a copy of) it.
2. Patching it.
3. Linking it with closed source code.
4. Distributing the result.

(If that's not what you have in mind, maybe we are at cross purposes).

Step #1 is illegal unless you have a licence. The burden of proof is on
you to show that you were allowed to do it.


> 
> That is why I want you to actually look up the letter of the law,
> because if the specific action being done isn't in the letter of the
> law, then those claiming copyright have an uphill battle ahead of
> them.
> 

I'm not going to go look up whatever statute says "you can't make a copy
of copyrighted stuff" =P

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 7:14:19 PM Michael Orlitzky wrote:
> On 08/19/2015 06:21 PM, Rich Freeman wrote:
> >>
> >> Copyright law makes everything illegal. Downloading the source and
> >> reading it is illegal. Why wouldn't it be illegal? The copyright holders
> >> have made it clear that you have no license to do so.
> >>
> > 
> > If I distribute a binary kernel module, I'm not copying anything that
> > I didn't write.  I'm the copyright holder of the binary kernel module.
> > 
> 
> Anything you can do without the kernel source code is legal, sure. But
> we're talking about...
> 
> 1. Downloading the kernel source (making a copy of) it.
> 2. Patching it.
> 3. Linking it with closed source code.
> 4. Distributing the result.
> 
> (If that's not what you have in mind, maybe we are at cross purposes).
> 
> Step #1 is illegal unless you have a licence. The burden of proof is on
> you to show that you were allowed to do it.

You have the license, the GPL allows you to do steps 1-3. Step 4 is only 
illegal if it's a derived work, so the question, as Rich stated, is whether or 
nor is a derived work.

The law is not clear about that. But how can it not be a derived work if it 
doesn't work without it?

> > 
> > That is why I want you to actually look up the letter of the law,
> > because if the specific action being done isn't in the letter of the
> > law, then those claiming copyright have an uphill battle ahead of
> > them.
> > 
> 
> I'm not going to go look up whatever statute says "you can't make a copy
> of copyrighted stuff" =P
> 
> 

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 07:40 PM, Fernando Rodriguez wrote:
>>
>> 1. Downloading the kernel source (making a copy of) it.
>> 2. Patching it.
>> 3. Linking it with closed source code.
>> 4. Distributing the result.
>>
>> (If that's not what you have in mind, maybe we are at cross purposes).
>>
>> Step #1 is illegal unless you have a licence. The burden of proof is on
>> you to show that you were allowed to do it.
> 
> You have the license, the GPL allows you to do steps 1-3.

The GPL would, if the authors granted it to you, but they don't.
Selectively quoting...

  4. You may not copy, modify, sublicense, or distribute the Program
     except as expressly provided under this License...

  5. You are not required to accept this License, since you have not
     signed it. However, nothing else grants you permission to modify
     or distribute the Program or its derivative works. These actions
     are prohibited by law if you do not accept this License...

The authors have been as clear as possible, even imposing a little
technical roadblock to the effect, that they do not grant you the GPL
under the aforementioned circumstances. The GPL faq mentions this,

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#LinkingWithGPL

so the intent of anyone releasing their code under GPL-2 is clear.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michel Catudal]

Le 2015-08-19 20:04, Michael Orlitzky a écrit :
> On 08/19/2015 07:40 PM, Fernando Rodriguez wrote:
>>> 1. Downloading the kernel source (making a copy of) it.
>>> 2. Patching it.
>>> 3. Linking it with closed source code.
>>> 4. Distributing the result.
>>>
>>> (If that's not what you have in mind, maybe we are at cross purposes).
>>>
>>> Step #1 is illegal unless you have a licence. The burden of proof is on
>>> you to show that you were allowed to do it.
>> You have the license, the GPL allows you to do steps 1-3.
> The GPL would, if the authors granted it to you, but they don't.
> Selectively quoting...
>
>    4. You may not copy, modify, sublicense, or distribute the Program
>       except as expressly provided under this License...
>
>    5. You are not required to accept this License, since you have not
>       signed it. However, nothing else grants you permission to modify
>       or distribute the Program or its derivative works. These actions
>       are prohibited by law if you do not accept this License...
>
> The authors have been as clear as possible, even imposing a little
> technical roadblock to the effect, that they do not grant you the GPL
> under the aforementioned circumstances. The GPL faq mentions this,
>
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#LinkingWithGPL
>
> so the intent of anyone releasing their code under GPL-2 is clear.
>
>
>
The changes made have for reason to keep people from having an acceptable display. This would not hold in court.
This move from the dev could seriously hurt the community on the long run for many reason.

No sane person will accept a crappy display. If the dev do not care it is likely that they are not using Linux as a desktop so you should stick to their windows, mac, xbox or playstation and stop pissing off the Linux users.

Michel

-- 
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Dale]

Michel Catudal wrote:
> Le 2015-08-19 20:04, Michael Orlitzky a écrit :
>> On 08/19/2015 07:40 PM, Fernando Rodriguez wrote:
>>>> 1. Downloading the kernel source (making a copy of) it.
>>>> 2. Patching it.
>>>> 3. Linking it with closed source code.
>>>> 4. Distributing the result.
>>>>
>>>> (If that's not what you have in mind, maybe we are at cross purposes).
>>>>
>>>> Step #1 is illegal unless you have a licence. The burden of proof
>>>> is on
>>>> you to show that you were allowed to do it.
>>> You have the license, the GPL allows you to do steps 1-3.
>> The GPL would, if the authors granted it to you, but they don't.
>> Selectively quoting...
>>
>>    4. You may not copy, modify, sublicense, or distribute the Program
>>       except as expressly provided under this License...
>>
>>    5. You are not required to accept this License, since you have not
>>       signed it. However, nothing else grants you permission to modify
>>       or distribute the Program or its derivative works. These actions
>>       are prohibited by law if you do not accept this License...
>>
>> The authors have been as clear as possible, even imposing a little
>> technical roadblock to the effect, that they do not grant you the GPL
>> under the aforementioned circumstances. The GPL faq mentions this,
>>
>> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#LinkingWithGPL
>>
>>
>> so the intent of anyone releasing their code under GPL-2 is clear.
>>
>>
>>
> The changes made have for reason to keep people from having an
> acceptable display. This would not hold in court.
> This move from the dev could seriously hurt the community on the long
> run for many reason.
>
> No sane person will accept a crappy display. If the dev do not care it
> is likely that they are not using Linux as a desktop so you should
> stick to their windows, mac, xbox or playstation and stop pissing off
> the Linux users.
>
> Michel
>


That's why I said earlier, if the kernel devs don't like that Nvidia is
distributing their drivers as binaries, let them protest with their
crappy display.  For the rest of us that want the official Nvidia
drivers, let us use them like we been doing for ages now.  If I want
open source video drivers, I know how to get them.  Thing is, I want
what I have now.  I also want to be able to update my kernel and drivers
on occasion too. 

So, kernel devs, stare at a console all you want but I want a GUI with
Nvidia drivers, I'm guessing the ATI users what their ATI drivers as well. 

What crap!!

Dale

:-)  :-) 

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 8:04:01 PM Michael Orlitzky wrote:
> On 08/19/2015 07:40 PM, Fernando Rodriguez wrote:
> >>
> >> 1. Downloading the kernel source (making a copy of) it.
> >> 2. Patching it.
> >> 3. Linking it with closed source code.
> >> 4. Distributing the result.
> >>
> >> (If that's not what you have in mind, maybe we are at cross purposes).
> >>
> >> Step #1 is illegal unless you have a licence. The burden of proof is on
> >> you to show that you were allowed to do it.
> > 
> > You have the license, the GPL allows you to do steps 1-3.
> 
> The GPL would, if the authors granted it to you, but they don't.
> Selectively quoting...
> 
>   4. You may not copy, modify, sublicense, or distribute the Program
>      except as expressly provided under this License...
> 
>   5. You are not required to accept this License, since you have not
>      signed it. However, nothing else grants you permission to modify
>      or distribute the Program or its derivative works. These actions
>      are prohibited by law if you do not accept this License...
> 
> The authors have been as clear as possible, even imposing a little
> technical roadblock to the effect, that they do not grant you the GPL
> under the aforementioned circumstances. The GPL faq mentions this,
> 
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#LinkingWithGPL
> 
> so the intent of anyone releasing their code under GPL-2 is clear.

What's the purpose of these quotes?
Neither of them says it doesn't allow steps 1-3. Instead of doing selective 
reading you should read the whole thing. If that's too much just read the first 
few questions under "General understanding of the GPL" on the FAQ.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 08:37 PM, Fernando Rodriguez wrote:
> 
> What's the purpose of these quotes?
> Neither of them says it doesn't allow steps 1-3. Instead of doing selective 
> reading you should read the whole thing. If that's too much just read the first 
> few questions under "General understanding of the GPL" on the FAQ.
> 

The point was that the GPL doesn't allow shit unless the copyright
holders grant you the license in the first place.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michel Catudal]

Le 2015-08-19 20:48, Michael Orlitzky a écrit :
> On 08/19/2015 08:37 PM, Fernando Rodriguez wrote:
>> What's the purpose of these quotes?
>> Neither of them says it doesn't allow steps 1-3. Instead of doing selective
>> reading you should read the whole thing. If that's too much just read the first
>> few questions under "General understanding of the GPL" on the FAQ.
>>
> The point was that the GPL doesn't allow shit unless the copyright
> holders grant you the license in the first place.
>
>
Then why is it that the changes only allows shit?

-- 
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 8:48 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/19/2015 08:37 PM, Fernando Rodriguez wrote:
>>
>> What's the purpose of these quotes?
>> Neither of them says it doesn't allow steps 1-3. Instead of doing selective
>> reading you should read the whole thing. If that's too much just read the first
>> few questions under "General understanding of the GPL" on the FAQ.
>>
>
> The point was that the GPL doesn't allow shit unless the copyright
> holders grant you the license in the first place.
>

And they have, in writing.  You can copy the kernel all you want under
the terms of the GPL.

If you want to redistribute the kernel or a derivative work of it,
then you need to also distribute your sources.  A binary module author
isn't doing that, so they don't need anybody's permission.

You only need a license to do things that are forbidden by copyright
law.  In general you can't bind licenses to unrelated activities.  I
can't say that you have the right to use my software as long as you
don't beat your wife.  Well, I can say it, but no court would enforce
it.  Likewise you can't give somebody permission to use GPL software
under the condition that they don't distribute other software which
has nothing to do with your software other than containing a few
symbol names in the linking table.

Try this exercise.  Go buy a Quran.  Now replace every occurrence of
the word "Mohammed" with "Fred."  This email is now dynamically linked
to a book that I've never bought or read.  Are you going to argue that
this email is a derivative work of the Quran?  Suppose I told you to
grab your scientology bible and rip out page 3.  Is that now grounds
for me to be sued by the Church of Scientology, on the basis that I
just cross-referenced their copyrighted work?  After all, I did quote
one of their page numbers.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 9:20:41 PM Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 8:48 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> > On 08/19/2015 08:37 PM, Fernando Rodriguez wrote:
> >>
> >> What's the purpose of these quotes?
> >> Neither of them says it doesn't allow steps 1-3. Instead of doing 
selective
> >> reading you should read the whole thing. If that's too much just read the 
first
> >> few questions under "General understanding of the GPL" on the FAQ.
> >>
> >
> > The point was that the GPL doesn't allow shit unless the copyright
> > holders grant you the license in the first place.
> >
> 
> And they have, in writing.  You can copy the kernel all you want under
> the terms of the GPL.
> 
> If you want to redistribute the kernel or a derivative work of it,
> then you need to also distribute your sources.  A binary module author
> isn't doing that, so they don't need anybody's permission.
> 
> You only need a license to do things that are forbidden by copyright
> law.  In general you can't bind licenses to unrelated activities.  I
> can't say that you have the right to use my software as long as you
> don't beat your wife.  Well, I can say it, but no court would enforce
> it.  Likewise you can't give somebody permission to use GPL software
> under the condition that they don't distribute other software which
> has nothing to do with your software other than containing a few
> symbol names in the linking table.
> 
> Try this exercise.  Go buy a Quran.  Now replace every occurrence of
> the word "Mohammed" with "Fred."  This email is now dynamically linked
> to a book that I've never bought or read.  Are you going to argue that
> this email is a derivative work of the Quran?  Suppose I told you to
> grab your scientology bible and rip out page 3.  Is that now grounds
> for me to be sued by the Church of Scientology, on the basis that I
> just cross-referenced their copyrighted work?  After all, I did quote
> one of their page numbers.

Try a different exercise. Go buy a Quran. Now use it as a cryptographic key to 
encrypt an email. Is the email now a derived work? That's no a perfect analogy 
but it's more like what happens when you dynamic link a library. 

It's not the symbols that are copyrighted, it's the code that those symbols 
load into your programs address space.

Here's a better example, see the Mona Lisa example in wikipedia[1]. Now, 
suppose I write a small program that downloads a Mona Lisa picture of the 
internet and displays it with a mustache overlaid? Is my program now a 
derivative work of the Mona Lisa? That's *exactly* what happens when you 
dynamic link to a library.

1. 
https://en.wikipedia.org/wiki/Derivative_work#Examples_of_derivative_works_under_U.S._law

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 10:37 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
>
> Try a different exercise. Go buy a Quran. Now use it as a cryptographic key to
> encrypt an email. Is the email now a derived work? That's no a perfect analogy
> but it's more like what happens when you dynamic link a library.

But that isn't what happens with dynamic linking.

In the paragraph below, insert word 1 after the 3rd word in place of
the xx, and insert word 2 after the 9th word in place of the xx.

This is an xx of dynamic linking.  I have a xx where various elements
are replaced with others.

Somebody else will tell you next week what word 1 and word 2 are.  He
owns the copyright on those words, but he will refer to them as word 1
and word 2.

Dynamic linking doesn't render code unreadable the way encryption
does.  It just means that not all of the code is actually present.
All the original code written by the author of the object file is
actually present, and in completely executable form except where it
accesses memory that isn't a part of the object file.  You can
actually execute parts of an object file as a result.

> It's not the symbols that are copyrighted, it's the code that those symbols
> load into your programs address space.

The symbols don't load anything.  The linker loads the external code
into RAM, and inserts its address into your own code where it
references the exported symbols.  In the example above my instructions
don't actually do anything.  They just tell you what to do when you
find out what words 1 and 2 are.

> Here's a better example, see the Mona Lisa example in wikipedia[1]. Now,
> suppose I write a small program that downloads a Mona Lisa picture of the
> internet and displays it with a mustache overlaid? Is my program now a
> derivative work of the Mona Lisa? That's *exactly* what happens when you
> dynamic link to a library.

That program would not be a derivative work of the Mona Lisa.  The
picture it displays would be a derivative work of the Mona Lisa.  The
analogy isn't perfect, but it is decent.

Executing the program might or might not be a violation of copyright,
but distributing the program itself would not be.  At most you could
argue it is inducing copyright violation, which is a horrible legal
argument, but admittedly one that US courts have seemed to embrace.
Go Mercia!

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 10:53:39 PM Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 10:37 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> >
> > Try a different exercise. Go buy a Quran. Now use it as a cryptographic key 
to
> > encrypt an email. Is the email now a derived work? That's no a perfect 
analogy
> > but it's more like what happens when you dynamic link a library.
> 
> But that isn't what happens with dynamic linking.
> 
> In the paragraph below, insert word 1 after the 3rd word in place of
> the xx, and insert word 2 after the 9th word in place of the xx.
> 
> This is an xx of dynamic linking.  I have a xx where various elements
> are replaced with others.
> 
> Somebody else will tell you next week what word 1 and word 2 are.  He
> owns the copyright on those words, but he will refer to them as word 1
> and word 2.
> 
> Dynamic linking doesn't render code unreadable the way encryption
> does.  It just means that not all of the code is actually present.
> All the original code written by the author of the object file is
> actually present, and in completely executable form except where it
> accesses memory that isn't a part of the object file.  You can
> actually execute parts of an object file as a result.

The point I was trying to make is that just like the email would be useless 
unless I have a Quran so will a program be useless without the library it 
depends on. I did say it wasn't a very good analogy.

> 
> > It's not the symbols that are copyrighted, it's the code that those 
symbols
> > load into your programs address space.
> 
> The symbols don't load anything.  The linker loads the external code
> into RAM, and inserts its address into your own code where it
> references the exported symbols.  In the example above my instructions
> don't actually do anything.  They just tell you what to do when you
> find out what words 1 and 2 are.

The linker/loader doesn't load anything either, it just tells the kernel to 
load it...the kernel doesn't load it either, it tells the cpu to do it and so 
on. The point is that the symbols are instructions too, they're just not 
executed by the processor but interpreted by the loader. It all starts with  
the developer's decision to link against the library in order to take 
advantage of _existing works_.

> > Here's a better example, see the Mona Lisa example in wikipedia[1]. Now,
> > suppose I write a small program that downloads a Mona Lisa picture of the
> > internet and displays it with a mustache overlaid? Is my program now a
> > derivative work of the Mona Lisa? That's *exactly* what happens when you
> > dynamic link to a library.
> 
> That program would not be a derivative work of the Mona Lisa.  The
> picture it displays would be a derivative work of the Mona Lisa.  The
> analogy isn't perfect, but it is decent.
> 
> Executing the program might or might not be a violation of copyright,
> but distributing the program itself would not be.  At most you could
> argue it is inducing copyright violation, which is a horrible legal
> argument, but admittedly one that US courts have seemed to embrace.
> Go Mercia!

Yet just about everyone would agree that if I fireup gimp and edit the picture 
and save it as a jpg would be a derived work. But for an end user there's no 
difference. The difference is only in the implementation. Both files contain 
binary code, one is interpreted by the cpu the other by an image viewer. One 
is statically linked to the original work the other dynamically.

If this does goes to court a judge will have to determine if the letter of the 
law still serves it's intended purpose if it doesn't (and it obviously 
doesn't) then it's obsolete and the loophole needs to be patched.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Thu, Aug 20, 2015 at 3:24 AM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
>
> The point I was trying to make is that just like the email would be useless
> unless I have a Quran so will a program be useless without the library it
> depends on. I did say it wasn't a very good analogy.

Arguably the library is also useless without the program that links to
it.  I don't think whether something is useful on its own really is a
factor in establishing that it is a derived work.

Rifftrax is generally considered to not be a derived work of the
movies it is associated with.  And yet, it is of limited usefulness on
its own.  At least, it is no more useful than a program is without its
linked library (a program without its linked libraries could possibly
be useful in some ways).

>>
>> That program would not be a derivative work of the Mona Lisa.  The
>> picture it displays would be a derivative work of the Mona Lisa.  The
>> analogy isn't perfect, but it is decent.
>>
>
> Yet just about everyone would agree that if I fireup gimp and edit the picture
> and save it as a jpg would be a derived work. But for an end user there's no
> difference. The difference is only in the implementation. Both files contain
> binary code, one is interpreted by the cpu the other by an image viewer. One
> is statically linked to the original work the other dynamically.

The analogy still holds.  Gimp isn't a derived work of the Mona Lisa.
Your email telling me to draw a mustache on top of it isn't a derived
work of the Mona Lisa.  Even a picture of a mustache stored in a file
with the same dimensions of your picture of the Mona Lisa positioned
so that it ends up right over her lips isn't a derived work of the
Mona Lisa.  It isn't a derived work until you actually save it.

In the same way a kernel module isn't a derived work of the kernel.
The combined kernel+module image in RAM would be.

>
> If this does goes to court a judge will have to determine if the letter of the
> law still serves it's intended purpose if it doesn't (and it obviously
> doesn't) then it's obsolete and the loophole needs to be patched.

There is plenty of history to suggest that derivative works were never
intended to cover references.  A SparkNotes for a book can
comprehensively reference passages in a book and discuss every aspect
of its plot and is not considered a derivative work of the book.
Rifftrax is completely synced to the audio/video for a movie and is
not considered a derivative work.

I don't think this is a loophole.  The purpose of the derivative works
clause of copyright was so that I couldn't add one line to the kernel
and call it an original work and redistribute the whole thing under my
own copyright.  That would be a derivative work.  I can't even run the
thing through ROT13 or gzip and call it an original work - it is just
an adaptation that still contains most of the content of the original
in some way.  In the statue derivative works are works which contain
substantial portions of the original in some way.

A kernel module doesn't contain much of the kernel at all.  It just
contains some symbol names.

Similar arguments are made about fan fiction, and that is also an area
where the law has not been fully tested.  If I write a completely
original story that includes "Harry Potter" as a character most would
argue that it is fair use at worst as far as copyright is concerned.
If I write an extra chapter that is intended to go in the middle or
end of a Harry Potter novel, I'd probably be on similar ground.  While
cases around situations like these haven't been fully tried in court,
so far most indications are that courts have been reluctant to uphold
copyright claims against works like these, and decisions to the
contrary have mostly been reversed on appeal.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 8:04 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/19/2015 07:40 PM, Fernando Rodriguez wrote:
>>>
>>> 1. Downloading the kernel source (making a copy of) it.
>>> 2. Patching it.
>>> 3. Linking it with closed source code.
>>> 4. Distributing the result.
>>>
>>> (If that's not what you have in mind, maybe we are at cross purposes).
>>>
>>> Step #1 is illegal unless you have a licence. The burden of proof is on
>>> you to show that you were allowed to do it.
>>
>> You have the license, the GPL allows you to do steps 1-3.
>
> The GPL would, if the authors granted it to you, but they don't.
> Selectively quoting...
>
>   4. You may not copy, modify, sublicense, or distribute the Program
>      except as expressly provided under this License...

Great, then they can copy it under the terms of the license.  And
they're not redistributing the kernel, or any derived work of the
kernel, so the terms about distributing sources don't apply.

> The authors have been as clear as possible, even imposing a little
> technical roadblock to the effect, that they do not grant you the GPL
> under the aforementioned circumstances. The GPL faq mentions this,
>
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#LinkingWithGPL
>
> so the intent of anyone releasing their code under GPL-2 is clear.

So, who cares what they think?  They don't get to write the law.  When
Linus says stuff that is smart, I'll admire him for it.  When he says
stuff that is dumb, I'm not afraid to say that the emperor has no
clothes.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

Am Wed, 19 Aug 2015 21:13:01 -0400
schrieb Rich Freeman <rich0@gentoo.org>:

> So, who cares what they think?  They don't get to write the law.  When
> Linus says stuff that is smart, I'll admire him for it.  When he says
> stuff that is dumb, I'm not afraid to say that the emperor has no
> clothes.

What do you think of the input the lawyers he went to gave him [0]:

"Linus, however, believes that GPL-only exports are significant.

    I've talked to a lawyer or two, and (a) there's an absolutely _huge_
    difference and (b) they liked it.

    The fact is, the law isn't a blind and mindless computer that takes what
    you say literally. Intent matters a LOT. And using the xxx_GPL() version to
    show that it's an internal interface is very meaningful indeed.

    One of the lawyers said that it was a much better approach than trying to
    make the license explain all the details - codifying the intention in the
    code itself is not only more flexible, but a lot less likely to be
    misunderstood."

In the rest of the email [1] he writes:

    "I think both them said that anybody who were to change a xyz_GPL to the 
    non-GPL one in order to use it with a non-GPL module would almost 
    immediately fall under the "willful infringement" thing, and that it would 
    make it MUCH easier to get triple damages and/or injunctions, since they 
    clearly knew about it.

    I suspect programmers make horrible lawyers. They nitpick on details that 
    sane humans don't. I think programmers often end up forgetting about the 
    fact that human interactions don't work that way. Common sense makes a lot 
    of difference, and DWIM is not just possible, but it's the only thing that 
    matters.

		Linus"

[0] https://lwn.net/Articles/154602/
[1] https://lwn.net/Articles/154603/
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Thu, Aug 20, 2015 at 4:40 AM, Marc Joliet <marcec@gmx.de> wrote:
> Am Wed, 19 Aug 2015 21:13:01 -0400
> schrieb Rich Freeman <rich0@gentoo.org>:
>
>> So, who cares what they think?  They don't get to write the law.  When
>> Linus says stuff that is smart, I'll admire him for it.  When he says
>> stuff that is dumb, I'm not afraid to say that the emperor has no
>> clothes.
>
> What do you think of the input the lawyers he went to gave him [0]:

I don't know.  You didn't provide it, and neither did Linus.

Lawyers also don't have the authority to write the law.  In fact, in
every single case that goes to court there are at least two lawyers
who disagree on how the case should be resolved.

>     "I think both them said that anybody who were to change a xyz_GPL to the
>     non-GPL one in order to use it with a non-GPL module would almost
>     immediately fall under the "willful infringement" thing, and that it would
>     make it MUCH easier to get triple damages and/or injunctions, since they
>     clearly knew about it.

IF it were infringement, I agree.  It is a bit like putting a lock on
your door.  Even if the lock is easy to defeat it shows intent.  I
don't take issue with that argument.

However, if I stick a lock on somebody else's gate it doesn't make
them a trespasser if they cut it.  Linus doesn't get to change the
law.  He's just drawing a line in the sand.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 7:40 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
>
> The law is not clear about that. But how can it not be a derived work if it
> doesn't work without it?
>

A is only a derived work of B if the law says it is.

My pot isn't a derived work of my stove.  My browser isn't a derived
work of the kernel it runs on.

Copyright law doesn't talk about interoperability when it comes to
derived works.  It talks about translations, adaptations, etc.  These
are derived works because they incorporate substantial portions of the
original work.  MST3K incorporates substantial portions of the movies
they're parodying.  Rifftrax does not.  That is the difference.

A kernel module does not incorporate substantial portions of the kernel.

And interoperability is actually a legal defense against copyright.
If the only way to make something interoperate with something else is
to partially copy it, the court tends to view that as fair use.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Dale]

Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 7:40 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
>> The law is not clear about that. But how can it not be a derived work if it
>> doesn't work without it?
>>
> A is only a derived work of B if the law says it is.
>
> My pot isn't a derived work of my stove.  My browser isn't a derived
> work of the kernel it runs on.
>
> Copyright law doesn't talk about interoperability when it comes to
> derived works.  It talks about translations, adaptations, etc.  These
> are derived works because they incorporate substantial portions of the
> original work.  MST3K incorporates substantial portions of the movies
> they're parodying.  Rifftrax does not.  That is the difference.
>
> A kernel module does not incorporate substantial portions of the kernel.
>
> And interoperability is actually a legal defense against copyright.
> If the only way to make something interoperate with something else is
> to partially copy it, the court tends to view that as fair use.
>


I'm no lawyer but I do sometimes research court stuff, tho not this
topic.  This is my opinion.  I download a kernel, I compile it and then
I boot that kernel.  I download the Nvidia driver, install it and then
load that driver so that my video card works.  First, I'm not
distributing nothing.  I'm only using it.  Actually, likely few other
computers would work with my kernel config and Nvidia module since after
the compile and install, they tend to become machine specific,
especially on Gentoo.  Second, the two things are still two different
things.  The kernel is still the kernel and the Nvidia driver is still
the driver.  The driver just "plugs in" the kernel so that the GUI can
be displayed.  I'm sure a wall plug has a patent or something for its
design and purpose.  If I can't plug in my toaster or my puter, then
what is the point of having the plug at all? 

Basically, the kernel devs need to look at it like this.  If I can't
have a GUI on my puter, I can't "surf" the web.  If I can't surf the
web, what is the point of the puter or the kernel?  Just like, what
would be the point in me having a toaster if every company that produces
wall plugs tells me I can't use the plug for toasters?  I want a GUI.  I
also want my freaking toaster.  :-)

I think this is sort of the same point you are making by the way.  ;-) 
Here's hoping they get this sorted out before I have to go buy a Mac or
start using something besides a Linux kernel.  :-@  

Dale

:-)  :-) 

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 9:09:59 PM Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 7:40 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> >
> > The law is not clear about that. But how can it not be a derived work if 
it
> > doesn't work without it?
> >
> 
> A is only a derived work of B if the law says it is.

The letter of the law is constantly changing. I'll grant that your argument is 
more inline with the letter of the law because the law wasn't written with 
this specific case in mind. But the FSF's argument is more inline with it's 
spirit. Until a court decides one way or the other it's just a grey are so 
there's no point in arguing.

> My pot isn't a derived work of my stove.  My browser isn't a derived
> work of the kernel it runs on.
> 
> Copyright law doesn't talk about interoperability when it comes to
> derived works.  It talks about translations, adaptations, etc.  These
> are derived works because they incorporate substantial portions of the
> original work.  MST3K incorporates substantial portions of the movies
> they're parodying.  Rifftrax does not.  That is the difference.
> 
> A kernel module does not incorporate substantial portions of the kernel.
> 
> And interoperability is actually a legal defense against copyright.
> If the only way to make something interoperate with something else is
> to partially copy it, the court tends to view that as fair use.

The GPL symbols are not necessary for interoperability. For that you need 
little more that access to the hardware and an interface to userspace. Most of 
those GPL symbols are convenience routines to enable reuse of code among 
different subsystems and  drivers.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 10:25 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
> The GPL symbols are not necessary for interoperability. For that you need
> little more that access to the hardware and an interface to userspace. Most of
> those GPL symbols are convenience routines to enable reuse of code among
> different subsystems and  drivers.

Interesting argument.  You're suggesting that NVidia could simply
bypass the kernel entirely by running their code in ring 0 and
directly accessing the hardware and intercepting system calls before
the kernel, sort of like a TSR back in the 80s.

Sure, I guess it would work.  I don't think that is really the model
we want to be promoting though.  Instead of building their drivers on
kernel headers they'd basically be building their drivers off of
rootkits.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 10:43:05 PM Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 10:25 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> > The GPL symbols are not necessary for interoperability. For that you need
> > little more that access to the hardware and an interface to userspace. 
Most of
> > those GPL symbols are convenience routines to enable reuse of code among
> > different subsystems and  drivers.
> 
> Interesting argument.  You're suggesting that NVidia could simply
> bypass the kernel entirely by running their code in ring 0 and
> directly accessing the hardware and intercepting system calls before
> the kernel, sort of like a TSR back in the 80s.
>
>
> Sure, I guess it would work.  I don't think that is really the model
> we want to be promoting though.  Instead of building their drivers on
> kernel headers they'd basically be building their drivers off of
> rootkits.

No, that would be extreme. I'm suggesting they could do it with the non-GPLd 
exports. I'm against the GPL symbols from a technical point of view though.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michel Catudal]

Le 2015-08-19 19:14, Michael Orlitzky a écrit :
> On 08/19/2015 06:21 PM, Rich Freeman wrote:
>>> Copyright law makes everything illegal. Downloading the source and
>>> reading it is illegal. Why wouldn't it be illegal? The copyright holders
>>> have made it clear that you have no license to do so.
>>>
>> If I distribute a binary kernel module, I'm not copying anything that
>> I didn't write.  I'm the copyright holder of the binary kernel module.
>>
> Anything you can do without the kernel source code is legal, sure. But
> we're talking about...
>
> 1. Downloading the kernel source (making a copy of) it.
> 2. Patching it.
> 3. Linking it with closed source code.
> 4. Distributing the result.
>
> (If that's not what you have in mind, maybe we are at cross purposes).
>
> Step #1 is illegal unless you have a licence. The burden of proof is on
> you to show that you were allowed to do it.
>
>
>> That is why I want you to actually look up the letter of the law,
>> because if the specific action being done isn't in the letter of the
>> law, then those claiming copyright have an uphill battle ahead of
>> them.
>>
> I'm not going to go look up whatever statute says "you can't make a copy
> of copyrighted stuff" =P
>
>
>
All the Linux manufacturer has to do is provide a kernel with the bullshit parts removed. It can provide a script to install the proprietary driver.
A judge would throw out of court any ridiculous complaint about someone installing a good video driver on their computer because they do not like the trash that came with it.

Manufacturers of video cards have plenty of customers with Winblows and MAC. They cannot afford to release information that their competition can use to steal their market share.
Business is a very competitive market, industrial espionage is not the only thing companies have to worry about it.

Our choice here is either to have a decent display or crap, my choice is the first. For the dev of the kernel to attempt to keep us from having decent display is uncalled for.
The day I will use nouveau instead of the good nvidia driver as my father use to say, in the week of three thursdays.

-- 
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 7:14 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>
> Anything you can do without the kernel source code is legal, sure. But
> we're talking about...
>
> 1. Downloading the kernel source (making a copy of) it.

You're receiving a copy of it.  You don't need a license to download
something.  You'll notice that even the RIAA doesn't sue people who
download music - they sue people who UPLOAD it.  They are on far more
solid legal ground doing the latter.

> 2. Patching it.
> 3. Linking it with closed source code.

You're not linking the kernel with closed source code.  You're linking
closed source code with the kernel.  You're not making any changes to
the kernel itself in the process.  I'm not even sure why you'd have to
patch the kernel.

> 4. Distributing the result.

You're distributing the closed source part that you wrote.  You don't
have to redistribute the kernel, since the intended recipient of your
driver already has it.  The only bits of the kernel that end up in the
code you distribute are some symbol names.

>
> Step #1 is illegal unless you have a licence. The burden of proof is on
> you to show that you were allowed to do it.

Please cite a law that says you're not allowed to receive a copy of a
copyrighted work without a license.

Even if that were so, the GPL gives you permission to make as many
unmodified copies of the kernel as you wish.

> I'm not going to go look up whatever statute says "you can't make a copy
> of copyrighted stuff" =P

You're not copying anything that is copyrighted by Linus and co, and
that is my point.  Just what is AMD/Nvidia distributing that Linus
wrote?

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 09:05 PM, Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 7:14 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>>
>> Anything you can do without the kernel source code is legal, sure. But
>> we're talking about...
>>
>> 1. Downloading the kernel source (making a copy of) it.
> 
> You're receiving a copy of it.  You don't need a license to download
> something.  You'll notice that even the RIAA doesn't sue people who
> download music - they sue people who UPLOAD it.  They are on far more
> solid legal ground doing the latter.


Uhhhhhhhhhh



> Please cite a law that says you're not allowed to receive a copy of a
> copyrighted work without a license.

§ 106 . Exclusive rights in copyrighted works

Subject to sections 107 through 122, the owner of copyright under this
title has the exclusive rights to do and to authorize any of the following:

(1) to reproduce the copyrighted work in copies

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 9:12 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/19/2015 09:05 PM, Rich Freeman wrote:
>> On Wed, Aug 19, 2015 at 7:14 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>>>
>>> Anything you can do without the kernel source code is legal, sure. But
>>> we're talking about...
>>>
>>> 1. Downloading the kernel source (making a copy of) it.
>>
>> You're receiving a copy of it.  You don't need a license to download
>> something.  You'll notice that even the RIAA doesn't sue people who
>> download music - they sue people who UPLOAD it.  They are on far more
>> solid legal ground doing the latter.
>
> Uhhhhhhhhhh
>
>> Please cite a law that says you're not allowed to receive a copy of a
>> copyrighted work without a license.
>
> § 106 . Exclusive rights in copyrighted works
>
> Subject to sections 107 through 122, the owner of copyright under this
> title has the exclusive rights to do and to authorize any of the following:
>
> (1) to reproduce the copyrighted work in copies

When you download software you receive a copy.  You start out with
zero works.  Somebody sends you a copy of that work.  You write it to
disk.  You end up with the same number of copies as you were given.

Cite a court case that upholds a claim otherwise?

In any case, the Linux kernel authors have already given people
permission to make unmodified copies of the kernel, which is all that
is happening in step 1.  So, this is not an essential element of my
argument.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 09:24 PM, Rich Freeman wrote:
> 
> When you download software you receive a copy.  You start out with
> zero works.  Somebody sends you a copy of that work.  You write it to
> disk.  You end up with the same number of copies as you were given.
> 
> Cite a court case that upholds a claim otherwise?

https://en.wikipedia.org/wiki/UMG_Recordings,_Inc._v._MP3.com,_Inc.

I don't personally like or even believe in copyright, so I'm getting
sick of arguing for it. Don't take it the wrong way if I give up on this
thread =)

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 9:35 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/19/2015 09:24 PM, Rich Freeman wrote:
>>
>> When you download software you receive a copy.  You start out with
>> zero works.  Somebody sends you a copy of that work.  You write it to
>> disk.  You end up with the same number of copies as you were given.
>>
>> Cite a court case that upholds a claim otherwise?
>
> https://en.wikipedia.org/wiki/UMG_Recordings,_Inc._v._MP3.com,_Inc.
>

mp3.com uploaded music as well as downloading it.  Users didn't just
upload their songs to mp3.com.  They then accessed that music from
other computers, so mp3.com was redistributing the music.

Don't get me wrong, the recording studios claim that downloading music
is also illegal.  However in practice they've only pursued court cases
against distributors.

Here's the thing - propaganda is 90% of the battle for folks touting
copyright.  They only fight actual court cases that they think they're
very likely to win.  Fighting a court case and losing just encourages
people to ignore you.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/19/2015 10:39 PM, Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 9:35 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>> On 08/19/2015 09:24 PM, Rich Freeman wrote:
>>>
>>> When you download software you receive a copy.  You start out with
>>> zero works.  Somebody sends you a copy of that work.  You write it to
>>> disk.  You end up with the same number of copies as you were given.
>>>
>>> Cite a court case that upholds a claim otherwise?
>>
>> https://en.wikipedia.org/wiki/UMG_Recordings,_Inc._v._MP3.com,_Inc.
>>
> 
> mp3.com uploaded music as well as downloading it.  Users didn't just
> upload their songs to mp3.com.  They then accessed that music from
> other computers, so mp3.com was redistributing the music.
> 

That's just the first in a long list.

"Uploading is copying. Downloading is also copying. Unauthorized copying
is an unauthorized use that is governed by the copyright laws.
Therefore, unauthorized uploading and unauthorized downloading are
unauthorized uses governed by the copyright laws...."

http://cases.justia.com/ohio/supreme-court-of-ohio/1998-ohio-422.pdf?ts=1396139663

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 11:22 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>
> "Uploading is copying. Downloading is also copying. Unauthorized copying
> is an unauthorized use that is governed by the copyright laws.
> Therefore, unauthorized uploading and unauthorized downloading are
> unauthorized uses governed by the copyright laws...."
>
> http://cases.justia.com/ohio/supreme-court-of-ohio/1998-ohio-422.pdf?ts=1396139663

The party in this case was also uploading files, and it seems to me
that the mention of downloading was made in conjunction with him being
the uploader.  The downloading side of this argument was never really
litigated on its own since it would be moot to the infringement claim
since the party was also uploading.

I'd be more interested in a case where a court holds a party liable
for copyright infringement when the ONLY activity they took part in
was downloading a copyrighted work.  I've yet to hear of a copyright
holder even pursing such a case.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Fernando Rodriguez]

On Wednesday, August 19, 2015 5:28:37 PM Rich Freeman wrote:
> On Wed, Aug 19, 2015 at 3:06 PM, Fernando Rodriguez
> <frodriguez.developer@outlook.com> wrote:
> >
> > The illegal part is not loading it but distributing the blob that depends 
on
> > the GPL exports.
> 
> What makes it illegal?  Quote the text of the relevant statute or
> court case.  That is the issue here.  People argue that linking
> creates a derivative work, and I think that at best it only creates a
> derivative work after the image ends up in RAM.  The blob itself
> doesn't contain any kernel code, unless you count a bunch of symbol
> names.  And that is API copyrighting, which is a horrible idea (though
> one the US seems to be entertaining now all the same; Murcia!).

I'm not a lawyer but as I understand it, it's not on the "letter of the law" 
because it's a technical issue and the law hasn't caught up.

My view, and what I think is most in the spirit of the law, is that it is a 
derived work simply because it doesn't work without those GPL exports.

-- 
Fernando Rodriguez

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 7:30 PM, Fernando Rodriguez
<frodriguez.developer@outlook.com> wrote:
>
> I'm not a lawyer but as I understand it, it's not on the "letter of the law"
> because it's a technical issue and the law hasn't caught up.
>
> My view, and what I think is most in the spirit of the law, is that it is a
> derived work simply because it doesn't work without those GPL exports.
>

My car doesn't work without tires.  Does it mean that Kia needs a
license from Michelin to make cars?

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Tue, Aug 18, 2015 at 4:49 PM, Dale <rdalek1967@gmail.com> wrote:
>
> If you have any info on how to override this, I'd be glad to see it.
> Just a link or something would help.
>

I haven't tested it, but I'd think the simplest solution would be
something like this (which just turns EXPORT_SYMBOL_GPL into
EXPORT_SYMBOL, and should be a lot easier than fixing every export
that the drivers use):

diff --git a/include/linux/export.h b/include/linux/export.h
index 96e45ea..b1bc4c3 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -69,7 +69,7 @@ extern struct module __this_module;
        __EXPORT_SYMBOL(sym, "")

 #define EXPORT_SYMBOL_GPL(sym)                                 \
-       __EXPORT_SYMBOL(sym, "_gpl")
+       __EXPORT_SYMBOL(sym, "")

 #define EXPORT_SYMBOL_GPL_FUTURE(sym)                          \
        __EXPORT_SYMBOL(sym, "_gpl_future")


I really think that this kind of approach by the kernel devs isn't
really going to go anywhere.  It might cause companies like nvidia/ati
to just dump linux support, but it seems more likely that they'd just
play workaround games.  Maybe they create a GPL module that just
exposes all the APIs as non-GPL.  Maybe they make it clear that their
module is non-GPL, but have it report itself as GPL to the kernel.

I think the kernel devs would be hard-pressed to mount some kind of
GPL infringement lawsuit.  In general US courts have tended to block
attempts to use copyright/trademark/patents/etc simply to prevent
interoperability, and that is basically what this is.

And would we really want it any other way?  How is this not like
Brother sticking chips in their ink cartridges containing copyrighted
code, or the chip in lightning cables?

I do get the frustration of the kernel developers.  The GPU makers
should be competing on their GPUs, not on their drivers.  However,
Linux isn't their main market and forcing the issue is probably just
going to drive them to ignore it.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Michael Orlitzky]

On 08/18/2015 09:54 PM, Rich Freeman wrote:
> 
> I think the kernel devs would be hard-pressed to mount some kind of
> GPL infringement lawsuit.  In general US courts have tended to block
> attempts to use copyright/trademark/patents/etc simply to prevent
> interoperability, and that is basically what this is.

The entire point of the GPL is to "prevent interoperability" with people
who want to steal your work and take away its users' freedoms.


> And would we really want it any other way?  How is this not like
> Brother sticking chips in their ink cartridges containing copyrighted
> code, or the chip in lightning cables?

They are similar. The original GPL was a legal hack: to take copyright
and use it in a novel way, granting freedoms rather than restricting
them. Which coincidentally is how your example differs from
EXPORT_SYMBOL_GPL =)

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Tue, Aug 18, 2015 at 11:20 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 08/18/2015 09:54 PM, Rich Freeman wrote:
>>
>> I think the kernel devs would be hard-pressed to mount some kind of
>> GPL infringement lawsuit.  In general US courts have tended to block
>> attempts to use copyright/trademark/patents/etc simply to prevent
>> interoperability, and that is basically what this is.
>
> The entire point of the GPL is to "prevent interoperability" with people
> who want to steal your work and take away its users' freedoms.

That might be their purpose, but it is based on copyright law, which
does not share that purpose.

The GPL can't take away anybody's rights.  A license GIVES you rights.
It is copyright law which restricts you, and the GPL eases those
restrictions.

The law says that hanging out on somebody else's property without
permission is trespassing.  However, my neighbor can mow my lawn for
me if I give them permission.  That doesn't mean that they need
permission from me to mow their own lawn, because the whole basis for
needing permission was that they would be violating a law which no
longer applies.

The law says you can't make copies of the kernel source or binaries
without permission.  The GPL says that you can make copies under some
conditions.  The law doesn't say that you can't make something
inter-operable with a copyrighted work.  The GPL can't impose such a
restriction any more than I can tell my neighbor on which days he is
allowed to mow his own lawn.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

Am Tue, 18 Aug 2015 21:54:30 -0400
schrieb Rich Freeman <rich0@gentoo.org>:

> I do get the frustration of the kernel developers.  The GPU makers
> should be competing on their GPUs, not on their drivers.  However,
> Linux isn't their main market and forcing the issue is probably just
> going to drive them to ignore it.

I know that AMD is writing a new kernel module to be integrated into the kernel,
on top of which their proprietary driver will then operate (it is reported that
the open-source driver can/will also profit from this).  Thus it's the reality
*now* that at least one GPU manufacturers is trying to deal with this properly.

Personally, I am under the impression that the point where GPU manufacturers
could opt to ignore Linux completely passed some time ago (I'm no expert, but I
know that the gaming market isn't the only market for GPUs).

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[J. Roeleveld]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Wednesday, August 19, 2015 09:57:19 AM Marc Joliet wrote:
> Am Tue, 18 Aug 2015 21:54:30 -0400
> 
> schrieb Rich Freeman <rich0@gentoo.org>:
> > I do get the frustration of the kernel developers.  The GPU makers
> > should be competing on their GPUs, not on their drivers.  However,
> > Linux isn't their main market and forcing the issue is probably just
> > going to drive them to ignore it.
> 
> I know that AMD is writing a new kernel module to be integrated into the
> kernel, on top of which their proprietary driver will then operate (it is
> reported that the open-source driver can/will also profit from this).  Thus
> it's the reality *now* that at least one GPU manufacturers is trying to
> deal with this properly.
> 
> Personally, I am under the impression that the point where GPU manufacturers
> could opt to ignore Linux completely passed some time ago (I'm no expert,
> but I know that the gaming market isn't the only market for GPUs).

Interesting,

I don't seem to have any issues.

Kernel: 4.0.5
Nvidia: 352.30

--
Joost

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Jeremi Piotrowski]

On Tue, 18 Aug 2015, Dale wrote:

> I did some searching based on the config option you gave and I'm unable
> to find a way to override this myself.  It doesn't seem to be a setting
> I can put in make.conf or package.use etc either.  If this is the case,
> I may wish Nvidia would switch to open source but it sort of rubs me the
> wrong way that someone else is making the decision and me having no way
> to exercise my decision to use it anyway.   I don't care if Nvidia
> doesn't show its code as long as it works and it isn't spying on me or
> blowing up my house here. 

The issue is more of a legal one. The kernel has *always* been under the
GPLv2, so derivative work should also be under a compatible license.
Companies have frequently been violating the terms of the license or
applying their own interpretation of what constitutes derived work. 

The point is the kernel devs are *not* changing anything by modifying some
symbols to be exported GPL-only. Legally they have always been such, and
they are just now starting to enforce what has always been their
intention.  And it's their right to do so. If anyone is to blame then it's
nvidia and amd.

Ofcourse as a user with access to the source code you can modify it in any
way you like, as long as you don't redistribute it. Patch the kernel
sources, patch the module sources, contact the graphics card vendor and
demand a patch. But don't blame the kernel people.

I have nothing against proprietary/closed source kernel modules as long as
they comply with the terms of the licenses of open source software that
they are using. They expect the same from you...

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 5:19 AM, Jeremi Piotrowski
<jeremi.piotrowski@gmail.com> wrote:
> Companies have frequently been ...
> applying their own interpretation of what constitutes derived work.
>...
> I have nothing against proprietary/closed source kernel modules as long as
> they comply with the terms of the licenses of open source software that
> they are using. They expect the same from you...
>

It sounds like you not only expect them to comply with the license,
but also with the kernel devs personal interpretation of copyright
law.

(I realize I truncated the first sentence I quoted, but you did use
the word "or" so the second half has to be able to stand on its own.
If you hadn't said it I'd have just said it for you.)

I think the real issue here is what constitutes a "derived work."  I
suspect the GPU legal teams have given these practices a thumbs-up,
and there is probably a reason that the Linux foundation hasn't tried
to sue them over it.  The reason neither party talks about it openly
is probably because they can't be 100% sure which way a court will go
so it isn't in anybody's interest to stir things up.  However, that
won't stop the Linux devs from trying to get companies to not write
proprietary drivers, and it apparently isn't stopping driver devs from
releasing proprietary drivers.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Jeremi Piotrowski]

On Wed, 19 Aug 2015, Rich Freeman wrote:

> It sounds like you not only expect them to comply with the license,
> but also with the kernel devs personal interpretation of copyright
> law.

What is a license but a statement of the intent of the authors as to what
can and can't be done with their work? Well, it does have some legal force
too... 

If you'd try to take away their right to decide about that next thing
they'd do is modify the license to be even larger and explicitly cover all
corner cases. But the world of licenses is complex enough so the next best
thing is saying "this is GPLv2 and we consider this to be derived work".
You can try to bypass that but will hit walls such as EXPORT_SYMBOL_GPL.
And intent does matter in copyright law, if explicitly stated as in this
case.


> I think the real issue here is what constitutes a "derived work."  I
> suspect the GPU legal teams have given these practices a thumbs-up,
> and there is probably a reason that the Linux foundation hasn't tried
> to sue them over it.  

That has always been the issue but I'll allow myself to quote an email
on the matter:

---
Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: Linux GPL and binary module exception clause?
Original-Message-ID: <Pine.LNX.4.58.0312040753550.2055@home.osdl.org>
Date: Thu, 4 Dec 2003 15:59:35 GMT
Message-ID: <fa.j5ccqt9.1e20lop@ifi.uio.no>

On Thu, 4 Dec 2003, Jason Kingsland wrote:
> >  - anything that has knowledge of and plays with fundamental internal
> >    Linux behaviour is clearly a derived work. If you need to muck
> >    around
> >    with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?

It is really just documentation.

This is exactly so that it is more clear which cases are black-and-white,
and where people shouldn't even have to think about it for a single
second. It still doesn't make the gray area go away, but it limits it a
bit ("if you need this export, you're clearly doing something that
requires the GPL").

Note: since the kernel itself is under the GPL, clearly anybody can modify
the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
against the license per se. But it doesn't make a module that needs that
symbol any less needful of the GPL - exactly because the thing is just a
big cluehint rather than anything else.

            Linus
---

Apparently the Linux foundation considers some pieces to be *clearly*
GPL-only and these are marked as such. And I don't see a way for vendors
around this other than to avoid the usage of such symbols - this is what
they have done so far and this is what they will continue doing. If they
want their drivers to be useful to anyone using linux that is.


> The reason neither party talks about it openly
> is probably because they can't be 100% sure which way a court will go
> so it isn't in anybody's interest to stir things up.

Who wants to go court when the current scheme is effective. The whole
issue of "derivative work" is more applicable to binary kernel modules
anyway. In this case we have the source code, and the kernel module build
system will not allow a module that claims a certain license to use
certain symbols. They (vendors) can:

  a) change their license to say "GPL" but then people would be allowed to
     demand full source code from them including binary blobs.

  b) apply the patch you posted - not really practical, definitely
     wouldn't be popular but I don't really see how that would be illegal.
     Full GPL would apply to the kernel anyway.

  c) avoid the usage of such symbols.

and they will do c) because they really don't have a choice.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 8:31 AM, Jeremi Piotrowski
<jeremi.piotrowski@gmail.com> wrote:
> On Wed, 19 Aug 2015, Rich Freeman wrote:
>
>> It sounds like you not only expect them to comply with the license,
>> but also with the kernel devs personal interpretation of copyright
>> law.
>
> What is a license but a statement of the intent of the authors as to what
> can and can't be done with their work? Well, it does have some legal force
> too...

The only reason that licenses matter at all is that they have legal
force.  They only matter to the degree that they do.

If I went around selling licenses to drive cars, anybody who bought
one would be a fool.  I have no rights to sell such licenses, and they
have no legal requirements to buy one from me.

Likewise, the fact that the kernel authors WANT to control linking to
their code means absolutely nothing.  They have no legal right to do
so, any more than a shovel manufacturer has the right to dictate what
kinds of holes I dig.

>
> If you'd try to take away their right to decide about that next thing
> they'd do is modify the license to be even larger and explicitly cover all
> corner cases.

And that would accomplish nothing, since companies would just ignore
any text which doesn't have a basis in law.

>
> That has always been the issue but I'll allow myself to quote an email
> on the matter:
> From: Linus Torvalds <torvalds@osdl.org>

The problem is that Linus's words mean nothing unless they're based in
law.  You don't need to quote Linus.  You need to quote laws, court
decisions, or treaties.  And none of them say a word about linking
creating a derived work.  And would we really want to live in a world
where they did?  Do you really want to need permission to use a
product in a manner the author didn't originally intend?

>
> Apparently the Linux foundation considers some pieces to be *clearly*
> GPL-only and these are marked as such. And I don't see a way for vendors
> around this other than to avoid the usage of such symbols

Why not just write API wrappers?  If somebody exposes an API called
do_this() using EXPORT_SYMBOL_GPL just write a module that is licensed
GPL, exposes an API called do_this_nonGPL() using EXPORT_SYMBOL, and
have do_this_nonGPL() just pass through a call to do_this().

This is a trivial measure to circumvent, as far as a I can tell.  It
is just a PITA to deal with.

What is next, randomizing all the function/variable names on each new
kernel release so that it is impossible to maintain any kernel code
outside of the tree?  Then we'll have smart configure scripts for
external modules that try to determine the right name to use and
wrapper header files.

>
> Who wants to go court when the current scheme is effective. The whole
> issue of "derivative work" is more applicable to binary kernel modules
> anyway. In this case we have the source code, and the kernel module build
> system will not allow a module that claims a certain license to use
> certain symbols. They (vendors) can:
>
>   a) change their license to say "GPL" but then people would be allowed to
>      demand full source code from them including binary blobs.

All they have to do is have the human-readable license say non-GPL,
and have it report GPL to the kernel, and not ship the source.  The
only recourse anybody has is to sue them, and it is doubtful that a
court is going to force them to comply, as they clearly indicated
their intent to not release the code as GPL.  You might be able to get
away with redistributing the blob since the situation is a bit
ambiguous, but I doubt the driver manufacturers care that much if you
redistribute their blobs.

I remember a fiasco a few years ago when a vendor exported the license
as something like "GPL\0 does not apply."

>
>   b) apply the patch you posted - not really practical, definitely
>      wouldn't be popular but I don't really see how that would be illegal.
>      Full GPL would apply to the kernel anyway.
>
>   c) avoid the usage of such symbols.
>
> and they will do c) because they really don't have a choice.
>

As I pointed out they can just write a wrapper that exports GPL and
re-exports all the symbols.

Also, you stated that the check is implemented in the build system.  I
don't know if that is true, but if it is, then the module can simply
be built using a patched build system.  I suspect the check is really
in the module loader, which the module builder would not have control
over.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Jeremi Piotrowski]

On Wed, 19 Aug 2015, Rich Freeman wrote:

> On Wed, Aug 19, 2015 at 8:31 AM, Jeremi Piotrowski
> <jeremi.piotrowski@gmail.com> wrote:
> > On Wed, 19 Aug 2015, Rich Freeman wrote:
> >
> >> It sounds like you not only expect them to comply with the license,
> >> but also with the kernel devs personal interpretation of copyright
> >> law.
> >
> > What is a license but a statement of the intent of the authors as to what
> > can and can't be done with their work? Well, it does have some legal force
> > too...
> 
> The only reason that licenses matter at all is that they have legal
> force.  They only matter to the degree that they do.

This discussion has been going on ever since the kernel was first
conceived, and some matters are still not entirely clear. I have tried
reading about the subject and the discussion is always the same as the one
we're having in this thread.

What I consider a final word on the matter is pretty much written here:

https://lwn.net/Articles/154602/

briefly: the kernel devs *have* consulted lawyers and believe EXPORT_SYMBOL_GPL 
has *some* legal meaning.

But I am not a lawyer, nor do I want to be so let's tune down the law
stuff and get back to technical issues.

> > If you'd try to take away their right to decide about that next thing
> > they'd do is modify the license to be even larger and explicitly cover all
> > corner cases.
> 
> And that would accomplish nothing, since companies would just ignore
> any text which doesn't have a basis in law.

They could, but I was under the impression that by using licensed software
you agree to follow it's terms. And the binding nature of licenses is
codified in copyright law.

> The problem is that Linus's words mean nothing unless they're based in
> law.  You don't need to quote Linus.  You need to quote laws, court
> decisions, or treaties.  

Copyright law talks of licenses. Linus' talks about the license under
which the kernel is licensed. Ergo, seems to me as though his words
should have some authority, but I won't argue that.

> And none of them say a word about linking creating a derived work.

The FSF says that and who knows if they're actually right, but I believe
so far everyone generally complies with their interpretation.

> And would we really want to live in a world where they did?  Do you
> really want to need permission to use a product in a manner the author
> didn't originally intend?

Proprietary licenses already say that I can't do that, and it's the free
licenses that tell me I can do whatever I want as long as I release the
sources. Sounds reasonable to me.

But again, I'm speaking mostly out of common sense and opinion here.
Neither one of us is going to go around citing cases and laws as that
would be a waste of bandwidth.

>
> Why not just write API wrappers?  If somebody exposes an API called
> do_this() using EXPORT_SYMBOL_GPL just write a module that is licensed
> GPL, exposes an API called do_this_nonGPL() using EXPORT_SYMBOL, and
> have do_this_nonGPL() just pass through a call to do_this().

From what I gather online, this is actually what Nvidia does (or did).
They have an LGPL wrapper in their module, which interfaces with the
kernel, and then talks to their proprietary blob. This [1] stackoverflow
answer has a nice picture:

    /------------.-\
    | Kernel       |
    |              |
    |   /--------\ |
    |   | Module | |     /-------------------\
    |   | (LGPL) <========> proprietary code |
    |   \--------/ |     \-------------------/
    \--------------/

[1]: http://stackoverflow.com/a/2721696

So they already go out of their way to comply with the terms of the kernel
license. But they also need to deal with the breakage on each update.


> All they have to do is have the human-readable license say non-GPL,
> and have it report GPL to the kernel, and not ship the source.  The
> only recourse anybody has is to sue them, and it is doubtful that a
> court is going to force them to comply, as they clearly indicated
> their intent to not release the code as GPL.  

On the other hand they would also be clearly indicating to others that
their code is GPL (if they did in fact add MODULE_LICENSE("GPL")). I may
be wrong here, but if that is not in the least bit ambiguous then shoot me.


> Also, you stated that the check is implemented in the build system.  I
> don't know if that is true, but if it is, then the module can simply
> be built using a patched build system.  I suspect the check is really
> in the module loader, which the module builder would not have control
> over.

Some reasearch tells me that this checking is implemented in both the build
system (consider it a warning) and in the module loader. 

To me it seems like it is not hard to bypass, but it would be *atleast*
indecent.

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 6:31 PM, Jeremi Piotrowski
<jeremi.piotrowski@gmail.com> wrote:
>
> They could, but I was under the impression that by using licensed software
> you agree to follow it's terms. And the binding nature of licenses is
> codified in copyright law.

You don't need a license to use software.  You need a license to copy software.

>
> Copyright law talks of licenses. Linus' talks about the license under
> which the kernel is licensed. Ergo, seems to me as though his words
> should have some authority,

All law talks of people.  I'm a person.  Therefore it sounds like my
words should have some authority.

That really is no different an argument.  You can't just stick
anything you want under the heading "license agreement" and enforce
it.

> but I won't argue that.

Uh, you just did.

>
>> And none of them say a word about linking creating a derived work.
>
> The FSF says that and who knows if they're actually right, but I believe
> so far everyone generally complies with their interpretation.

Well, you're talking to somebody who doesn't, so "everyone" is a bit
of a strong word.

>
>> And would we really want to live in a world where they did?  Do you
>> really want to need permission to use a product in a manner the author
>> didn't originally intend?
>
> Proprietary licenses already say that I can't do that, and it's the free
> licenses that tell me I can do whatever I want as long as I release the
> sources. Sounds reasonable to me.

I see, and because proprietary licenses purport to do all kinds of
horrible things, we ought to emulate them?  I don't suggest that those
licenses are any more legal with regard to these specific details.

>
> But again, I'm speaking mostly out of common sense and opinion here.
> Neither one of us is going to go around citing cases and laws as that
> would be a waste of bandwidth.

It wouldn't waste much bandwidth, because there aren't any relevant
laws or cases.  That is my whole point.  I can't cite them, because
they don't exist.  In the absence of law, there is liberty.

The onus is really on you to prove that somebody ISN'T allowed to do
something, not for them to prove that they can.


>
>> All they have to do is have the human-readable license say non-GPL,
>> and have it report GPL to the kernel, and not ship the source.  The
>> only recourse anybody has is to sue them, and it is doubtful that a
>> court is going to force them to comply, as they clearly indicated
>> their intent to not release the code as GPL.
>
> On the other hand they would also be clearly indicating to others that
> their code is GPL (if they did in fact add MODULE_LICENSE("GPL")). I may
> be wrong here, but if that is not in the least bit ambiguous then shoot me.

I guess that is why I said that it is a bit ambiguous in the part that
you chose not to quote:
You might be able to get away with redistributing the blob since the
situation is a bit ambiguous, but I doubt the driver manufacturers
care that much if you redistribute their blobs.

Here is the thing, you can use the law as a sword or a shield.  You
want to use it as a sword, which puts the onus on you to prove that
the law says what you think it says to take any action at all.

Sure, if you argue the driver is really GPL you might be able to
defend yourself from a copyright claim by the author of the driver.
However, they really don't care if you redistribute it anyway.  On the
other hand, if you want to force them to release the source to their
driver you have an uphill battle.  Even if they released their driver
under the GPL that STILL doesn't compel them to release the source to
it.  It just means that YOU have to give anybody you distribute the
driver to any sources you were given.  Licenses are granted to the
recipient of code.  They don't affect the copyright holder.

>
> To me it seems like it is not hard to bypass, but it would be *atleast*
> indecent.
>

There is nothing indecent about bypassing the efforts of somebody who
wants to regulate the end-use of software.

-- 
Rich

Re: [gentoo-user] Re: [WAS: keyboard stops working] Recent kernels block the loading of non-GPL kernel modules

[Rich Freeman]

On Wed, Aug 19, 2015 at 6:31 PM, Jeremi Piotrowski
<jeremi.piotrowski@gmail.com> wrote:
>
> This discussion has been going on ever since the kernel was first
> conceived, and some matters are still not entirely clear.

Honestly, I don't think they'll be any consensus on this argument
until a court makes some kind of ruling.  That isn't likely to happen
anytime soon.  And I suspect that any ruling that gets made will be
wrong in any case.  But, it will at least have the force of law so
that even though you're wrong you can at least use it to ruin lives
with statutory minimums.

I don't really see a lot of profit in going back and forth on this.
I've had arguments on the lists with Greg KH over similar issues.
People have strong opinions, and there isn't a lot of case law, and
that makes for long arguments.  In the end people choose to believe
what they believe.  If you want to go with authority you're probably
best off sticking with the opinion you already have and you'll be in
good company.  Personally, I've never really cared that much whether
others think I'm right or not...  :)

-- 
Rich

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Michel Catudal]

Le 2015-08-16 17:07, walt a écrit :
> On Sun, 16 Aug 2015 21:48:04 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
>> On 16/08/2015 21:42, walt wrote:
>>> On Sun, 16 Aug 2015 18:58:27 +0200
>>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>    
>>>> On 16/08/2015 18:45, walt wrote:
>>>>> I've been seeing this keyboard problem for the past few weeks:
>>>>> after running some command from a bash prompt (haven't tried zsh
>>>>> yet) the keyboard stops working.  Almost like somebody unplugged
>>>>> the keyboard from its usb port (except that the LED on the
>>>>> keyboard stays lit so I know the power is still on).
>>>>>
>>>>> There are no error messages in journalctl or
>>>>> in /var/log/Xorg.0.log
>>>>>
>>>>> I don't know how to change to a console without using a
>>>>> ctrl-alt-Fn keystroke from the keyboard (anyone know if it's
>>>>> possible?).
>>>>>
>>>>> When I unplug the keyboard from the usb port I can see the kernel
>>>>> recognize the unplug event, which makes me think that it's not a
>>>>> kernel/usb bug or a broken wire in the keyboard cable.
>>>>>
>>>>> When I re-plug the keyboard into a usb port the keyboard
>>>>> immediately starts working normally again until the next time I
>>>>> happen to trigger the problem by running some black-magical
>>>>> command from a command prompt.  There is no particular command
>>>>> that causes it--it can be any arbitrary command AFAICT.
>>>>>
>>>>> Just one weird example:  I can be typing a URL in a web browser
>>>>> window when a bash command finishes running in a terminal window
>>>>> and the keyboard stops working in the middle of my typing :(
>>>>>
>>>>> Any debugging suggestions would be most welcome.
>>>>
>>>> First step (more to half the problem space than anything else):
>>>>
>>>> Does the same happen if you use another keyboard?
>>> I agree with your assessment -- and I will buy another usb keyboard
>>> tomorrow because I'm using the only one I have and this machine has
>>> no ps/2 ports.  Never thought I'd miss the ps/2 ports til now :)
>> I kind of assumed you'd have lots of spare keyboards lying around and
>> had already done the test :-)
> I do have spares, all ps/2 :-(
>
>> I recall something similar happening to me,
>> perhaps a year ago or longer. I tried to debug it and gave up, then
>> one day it was no longer happening. I assumed it was a fixed kernel
>> bug then promptly forgot all about it.
>>
>> While you are waiting on a new keyboard, do you have the same bug on
>> different kernels?
> Affirmative, and thereby hangs yet another woeful tale.  I've been
> running the gentoo-sources-3.14.xx series forever because I wearied of
> spending so many hours debugging unstable kernels.
>
> This morning I decided to take a giant leap forward all the way to
> 3.18.19 (BTW 3.18.20 is already on kernel.org) because, surely, I
> wouldn't need to debug a kernel as old as that, right?
>
> Wrong.  Linus and friends have been marking lots of existing kernel
> symbols with the SYMBOL_EXPORT_GNU macro, which was designed to block
> the loading of any kernel module not explicitly licensed as GNU
> software.  (see output of modinfo)
>
> x11-drivers/ati-drivers installs a proprietary binary blob (as does
> nvidia-drivers) so the linker refused even to link the kernel module
> into a .ko file, nevermind the kernel actually loading the module at
> runtime.
>
> The remedy for ati-drivers is well-hidden in a comment in a gentoo bug
> report that I found at oh-dark-hundred hours this morning.  Only two
> hours later I got the module installed and loaded :)
>
> But yes, kernel 3.18.19 still has my same keyboard halting problem, so
> I'm back to 3.14.50 until the ati-drivers package is patched.  I'm sure
> gentoo-sources-3.18.20 will be available almost immediately and I'm not
> going through that hell again.
>
>
>
I am running Kernel 4.0.5 with no problem with the keyboards. I did encounter one issue, I purchased a French Canadian keyboard off ebay, turned out that the computer box had to be close to the mouse/keyboard otherwise I either lost signal or it was very 
slow. It seemed that when I would connect and reconnect it would work correctly again. That mouse/keyboard combo was from HP.

Is your issue with Logitech remote mouse/keyboard? If so you may want to read about my experience on the subject.

I had an issue with Debian on an Olimex A20 Arm board, no issue with ArchLinux on the same board with the same kernel. I found out that the difference was some special options for HID support for Logitech that were disabled by default. Archlinux noticed 
but not debian, in the debian world they must think that nobody uses logitech devices.

This morning I downloaded the latest kernel from sunxi that supports the mali GPU (3.4.103) for my old Mele A2000G, I wanted to upgrade it to Gentoo from SuSE. Someone seemed to have backport the debian bug into it as my logitech keyboard didn't work. 
After I enabled the HID special support for Logitech, both mouse and keyboard now work perfectly.


Michel

-- 
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Sun, 16 Aug 2015 19:27:41 -0400
Michel Catudal <mcatudal@comcast.net> wrote:

> > But yes, kernel 3.18.19 still has my same keyboard halting problem,
> > so I'm back to 3.14.50 until the ati-drivers package is patched.
> > I'm sure gentoo-sources-3.18.20 will be available almost
> > immediately and I'm not going through that hell again.
> >
> >
> >  
> I am running Kernel 4.0.5 with no problem with the keyboards.

Okay, thanks, that's good to know.

I'm aware that I'm mixing posts about video drivers in the same thread
(that I started) about keyboard problems, but that's no accident:  both
topics involve kernel device drivers *and* differences between kernel
versions.  I think the two apparently different problems are related.

<snipped for brevity>

> Someone seemed to have backport the debian bug
> into it as my logitech keyboard didn't work.

Yes, I wonder if some of the problems I'm having are caused by the
patches to gentoo-sources and/or ati-drivers that were committed by our
gentoo devs, or are my problems coming from upstream?  I have no idea.

> After I enabled the HID
> special support for Logitech, both mouse and keyboard now work
> perfectly.

Heh.  I just ordered a replacement Logitech USB keyboard from
amazon.com.  I picked the Logitech because it was from a company
(Logitech) whose name I recognize, as opposed to the other keyboards
that amazon offers under its own brand.

If my new Logitech keyboard fails to work correctly I will try enabling
the special HID support in whatever kernel(s) I'm using at the moment.
(Three days from now...who knows?)

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Michel Catudal]

Le 2015-08-16 21:43, walt a écrit :
> On Sun, 16 Aug 2015 19:27:41 -0400
> Michel Catudal <mcatudal@comcast.net> wrote:
>
>>> But yes, kernel 3.18.19 still has my same keyboard halting problem,
>>> so I'm back to 3.14.50 until the ati-drivers package is patched.
>>> I'm sure gentoo-sources-3.18.20 will be available almost
>>> immediately and I'm not going through that hell again.
>>>
>>>
>>>   
>> I am running Kernel 4.0.5 with no problem with the keyboards.
> Okay, thanks, that's good to know.
>
> I'm aware that I'm mixing posts about video drivers in the same thread
> (that I started) about keyboard problems, but that's no accident:  both
> topics involve kernel device drivers *and* differences between kernel
> versions.  I think the two apparently different problems are related.
>
> <snipped for brevity>
>
>> Someone seemed to have backport the debian bug
>> into it as my logitech keyboard didn't work.
> Yes, I wonder if some of the problems I'm having are caused by the
> patches to gentoo-sources and/or ati-drivers that were committed by our
> gentoo devs, or are my problems coming from upstream?  I have no idea.

A patch for bugs should be checked so it doesn't create other bugs. When they tried to fix a problem with some keyboards they destroyed the support for Logitech keyboards.
I have several remote keyboards and I find them to be the ones that works the best.

This may not be the only part that is problematic right now in the latest updates in Gentoo.
Handbrake for instance no longer works. To get it to work I had to install the latest x264 (not the latest one from gentoo which doesn't work either)
In the process I also upgraded Handbrake to 0.10.2 which works on ArchLinux, I think that x264 might probably have been good enough. The 9999 version didn't even compile, likely due to some gentoo patches.

>> After I enabled the HID
>> special support for Logitech, both mouse and keyboard now work
>> perfectly.
> Heh.  I just ordered a replacement Logitech USB keyboard from
> amazon.com.  I picked the Logitech because it was from a company
> (Logitech) whose name I recognize, as opposed to the other keyboards
> that amazon offers under its own brand.
>
> If my new Logitech keyboard fails to work correctly I will try enabling
> the special HID support in whatever kernel(s) I'm using at the moment.
> (Three days from now...who knows?)
>
>
>


-- 
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[netfab]

Le 16/08/15 à 19:27, Michel Catudal a tapoté :
> the latest kernel from sunxi that supports the mali GPU (3.4.103) for
> my old Mele A2000G

[offtopic]

Latest up to date (3.4.108) can be found here [1].
It also embeds patchs and fixs from armbian [2].

¹. https://github.com/dan-and/linux-sunxi
². http://forum.armbian.com/

[/offtopic]

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[mcatudal]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]



----- Mail original -----

Le 16/08/15 à 19:27, Michel Catudal a tapoté : 
> the latest kernel from sunxi that supports the mali GPU (3.4.103) for 
> my old Mele A2000G 

[offtopic] 

Latest up to date (3.4.108) can be found here [1]. 
It also embeds patchs and fixs from armbian [2]. 

¹. https://github.com/dan-and/linux-sunxi 
². http://forum.armbian.com/ 

[/offtopic] 

------------------------ 

resp: 

I don't think it would be off topic since the message is about keyboard that stops working, which happened with that kernel as well. 

[offtopic] 

How do you bottom post with comcast webmail? I only see the Microsoft exploder way which is only top post. 

[/offtopic] 



[-- Attachment #2: Type: text/html, Size: 1392 bytes --]

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Michel Catudal]

Le 2015-08-17 03:17, netfab a écrit :
> Le 16/08/15 à 19:27, Michel Catudal a tapoté :
>> the latest kernel from sunxi that supports the mali GPU (3.4.103) for
>> my old Mele A2000G
> [offtopic]
>
> Latest up to date (3.4.108) can be found here [1].
> It also embeds patchs and fixs from armbian [2].
>
> ¹. https://github.com/dan-and/linux-sunxi
> ². http://forum.armbian.com/
>
> [/offtopic]
>
>
michel linux-sunxi # make
   CHK     include/linux/version.h
   CHK     include/generated/utsrelease.h
make[1]: « include/generated/mach-types.h » est à jour.
   CALL    scripts/checksyscalls.sh
   CHK     include/generated/compile.h
   CHK     kernel/config_data.h
   CC      drivers/char/sunxi_mem/sunxi_physmem.o
drivers/char/sunxi_mem/sunxi_physmem.c:22:27: erreur fatale: mach/includes.h : Aucun fichier ou dossier de ce type
  #include <mach/includes.h>
                            ^
compilation terminée.
scripts/Makefile.build:307 : la recette pour la cible « drivers/char/sunxi_mem/sunxi_physmem.o » a échouée
make[3]: *** [drivers/char/sunxi_mem/sunxi_physmem.o] Erreur 1
scripts/Makefile.build:443 : la recette pour la cible « drivers/char/sunxi_mem » a échouée
make[2]: *** [drivers/char/sunxi_mem] Erreur 2
scripts/Makefile.build:443 : la recette pour la cible « drivers/char » a échouée
make[1]: *** [drivers/char] Erreur 2
Makefile:947 : la recette pour la cible « drivers » a échouée
make: *** [drivers] Erreur 2


-- 
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[netfab]

Le 17/08/15 à 21:13, Michel Catudal a tapoté :
> drivers/char/sunxi_mem/sunxi_physmem.c:22:27: erreur fatale:
> mach/includes.h : Aucun fichier ou dossier de ce type

I guess you should disable CONFIG_SUNXI_PHYS_MEM_ALLOCATOR since
anyway, this option is not available into official linux-sunxi-3.4.103,
it has been added by one armbian patch, and this driver seems broken
for your platform.

Re: [gentoo-user] [~amd64] Keyboard stops working several times/day

[Heiko Baums]

Am 16.08.2015 um 18:45 schrieb walt:
> I've been seeing this keyboard problem for the past few weeks:  after
> running some command from a bash prompt (haven't tried zsh yet) the
> keyboard stops working.  Almost like somebody unplugged the keyboard
> from its usb port (except that the LED on the keyboard stays lit so I
> know the power is still on).

I don't have this issue, but I guess you're using a terminal emulator in
a desktop environment.

Which terminal emulator and which desktop environment are you using?
Maybe the problem is just that the terminal emulator takes the control
over the keyboard or the desktop environment gives the keyboard controls
to the terminal emulator.

> There are no error messages in journalctl

That doesn't mean much.

> When I unplug the keyboard from the usb port I can see the kernel
> recognize the unplug event, which makes me think that it's not a
> kernel/usb bug or a broken wire in the keyboard cable.
> 
> When I re-plug the keyboard into a usb port the keyboard immediately
> starts working normally again until the next time I happen to trigger
> the problem by running some black-magical command from a command
> prompt.  There is no particular command that causes it--it can be any
> arbitrary command AFAICT.

Could theoretically also be a bug in systemd and/or udev? That wouldn't
surprise me. And it wouldn't surprise me if Poettering and Sievers would
blame the kernel developers for it again if it is a systemd and/or udev bug.

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Mon, 17 Aug 2015 18:51:34 +0200
Heiko Baums <lists@baums-on-web.de> wrote:

> Am 16.08.2015 um 18:45 schrieb walt:
> > I've been seeing this keyboard problem for the past few weeks:
> > after running some command from a bash prompt (haven't tried zsh
> > yet) the keyboard stops working.  Almost like somebody unplugged
> > the keyboard from its usb port (except that the LED on the keyboard
> > stays lit so I know the power is still on).  
> 
> I don't have this issue, but I guess you're using a terminal emulator
> in a desktop environment.
> 
> Which terminal emulator and which desktop environment are you using?
> Maybe the problem is just that the terminal emulator takes the control
> over the keyboard or the desktop environment gives the keyboard
> controls to the terminal emulator.

I see the keyboard problem in mate and xfce4 (the only ones I use
now).  I've wondered about the same things but I don't know how to
debug those possible scenarios.

At the moment I'm waiting for my new keyboard to arrive from amazon,
hoping to pin the blame on flakey hardware instead of flakey software.

Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[Heiko Baums]

Am 18.08.2015 um 04:04 schrieb walt:
> I see the keyboard problem in mate and xfce4 (the only ones I use
> now).  I've wondered about the same things but I don't know how to
> debug those possible scenarios.

And which terminal emulator are you using?

> At the moment I'm waiting for my new keyboard to arrive from amazon,
> hoping to pin the blame on flakey hardware instead of flakey software.

Somehow I doubt that it's the keyboard. I rather guess it's either a
wrong configuration of or a bug in the desktop environment, the terminal
emulator and/or systemd/udev.

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Tue, 18 Aug 2015 20:38:10 +0200
Heiko Baums <lists@baums-on-web.de> wrote:

> Am 18.08.2015 um 04:04 schrieb walt:
> > I see the keyboard problem in mate and xfce4 (the only ones I use
> > now).  I've wondered about the same things but I don't know how to
> > debug those possible scenarios.  
> 
> And which terminal emulator are you using?

I've seen the keyboard halting problem using xterm and gnome-terminal
(running under mate, not gnome, but it seems to work normally).

> 
> > At the moment I'm waiting for my new keyboard to arrive from amazon,
> > hoping to pin the blame on flakey hardware instead of flakey
> > software.  
> 
> Somehow I doubt that it's the keyboard. I rather guess it's either a
> wrong configuration of or a bug in the desktop environment, the
> terminal emulator and/or systemd/udev.

I plugged in my new keyboard two hours ago.  So far no problems but
that doesn't mean much yet.  I used the old keyboard for about ten
hours this morning and it stopped only once, about eight hours ago.

If the new keyboard works correctly for the rest of this week I'll be
convinced it was hardware :)

Re: [gentoo-user] [~amd64] Keyboard stops working several times/day

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

Am Sun, 16 Aug 2015 09:45:52 -0700
schrieb walt <w41ter@gmail.com>:

> I've been seeing this keyboard problem for the past few weeks:  after
> running some command from a bash prompt (haven't tried zsh yet) the
> keyboard stops working.  Almost like somebody unplugged the keyboard
> from its usb port (except that the LED on the keyboard stays lit so I
> know the power is still on).
> 
> There are no error messages in journalctl or in /var/log/Xorg.0.log
> 
> I don't know how to change to a console without using a ctrl-alt-Fn
> keystroke from the keyboard (anyone know if it's possible?).
> 
> When I unplug the keyboard from the usb port I can see the kernel
> recognize the unplug event, which makes me think that it's not a
> kernel/usb bug or a broken wire in the keyboard cable.
> 
> When I re-plug the keyboard into a usb port the keyboard immediately
> starts working normally again until the next time I happen to trigger
> the problem by running some black-magical command from a command
> prompt.  There is no particular command that causes it--it can be any
> arbitrary command AFAICT.
> 
> Just one weird example:  I can be typing a URL in a web browser window
> when a bash command finishes running in a terminal window and the
> keyboard stops working in the middle of my typing :(
> 
> Any debugging suggestions would be most welcome.

I don't think you mention precisely which (type of) keyboard you use within
this thread (please forgive me if I overlooked it). Does it happen to be a
Logitech "Unifying Receiver" model? My experience with the one I have is that
the relative position and orientation of the keyboard to the receiver can
strongly affect its reliability. Specifically, when the orientation is "bad",
the keyboard will stop working intermittently (workarounds included moving the
keyboard, but that never helped permanently). Moving the receiver to a USB slot
in the side of the desktop case (as opposed to one in the back), thus changing
its orientation by 90°, made the keyboard perform reliably again.

(My suspicion is that the directionality of the receiver and/or keyboard is not
uniform, though I can also imagine that the problem is (also?) caused by
interference with WLAN or something like that.)

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-user] Re: [~amd64] Keyboard stops working several times/day

[walt]

On Mon, 17 Aug 2015 23:21:54 +0200
Marc Joliet <marcec@gmx.de> wrote:

> I don't think you mention precisely which (type of) keyboard you use
> within this thread (please forgive me if I overlooked it). Does it
> happen to be a Logitech "Unifying Receiver" model? 

No I didn't mention which keyboard.  I tend to forget about wireless
devices because I don't have any.  This keyboard has a cable that plugs
directly into a usb port.  You're probably too young to remember
cables :)