Re: [linux-sunxi] Further Allwinner misbehaviour.
On Mon, Jun 29, 2015 at 02:19:00AM +0200, Henrik Nordström wrote: tor 2015-06-25 klockan 12:13 +0200 skrev Luc Verhaegen: The bad copyright headers is just stupidity. The direct loading of non-LGPLed binaries into LGPLed code is very deliberate. And to my best understanding is not in any way a violation of the LGPL license. Care to explain what I am missing? (ignoring any past state of these files) If the code had been GPL licensed then sure. But this is LGPL with it's implicit linking exception. Yes, you are right. I always assumed that LGPL only worked upwards, but after a very thorough read there is nothing in the license that clearly defines this. It does however seriously push the boundary of derivative work, not only because it is being loaded into the LGPLed library and does not work standalone or with other software, but more importantly because this .so does not function without LGPLed infrastructure provided in the top level software. The line becomes very blurry here, and whether this is derivative work or not will probably differ upon which lawyer you ask. What is clear however is that Allwinner can no longer feign innocence, lack of information, lack of knowledge, lack of understanding or just plaing old stupidity. It clearly is very much aware of what its legal obligations are, and is very actively feeling for where those boundaries truly lie, and where the lines of the LGPL license become blurry. Allwinner is trying to get away with the maximum of what it thinks it can get away with, and nothing has changed. Allwinner has not learned a single thing, and still is actively hostile towards free software, and has no real intention of proactively working with the linux sunxi community and its customers. While we all knew that to be true, this action is solid proof to that end. It is time to extend the negative marketing campaign to some of Allwinners customers, and truly hit Allwinner where it hurts. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: TRRS on Banana Pro and Orange Pi
No idea about Orange Pi. But if you can confirm the Banana Pro's pinout it would help if you add this stuff to http://linux-sunxi.org/Banana_Pro#Tips.2C_Tricks.2C_Caveats Thanks. I can't confirm it yet, but I added the corresponding info on that page. Stefan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Porting the sunxi-gslx680 driver to ACPI (and DeviceTree)
Hello, This might be slightly off-topic, but I do think it will be interesting to some people here, so please read on. I recently acquired a tablet based on the Intel Atom Z3735G SoC (Baytrail microarchitecture). The tablet came with Windows 8.1 preinstalled, which isn't of much interest to me. Debian 8 runs quite well - except that half the hardware isn't working. Of particular interest is the touch screen: It's a Silead GSL1680, which hasn't been used in x86 hardware much, as far as I know. All of the drivers I could find for this controller seem to be custom-built for specific Android devices. I also found the userspace driver by Sergio Costas. It seems much more useful, but has a drawback: You need to manually figure out the exact hardware pin assignments and create a custom launcher script for every device model. And it doesn't seem like it's guaranteed to work. I haven't been successful so far. So, that got me thinking... Wouldn't it be better to have a kernel driver, optimally even in mainline Linux, that works everywhere? There are a few pros and cons to that approach. + Hardware configuration can be automatically extracted from the ACPI DSDT or the DeviceTree by the kernel + Much of the basic HID/I2C/Interrupt/GPIO functionality is built in and doesn't need to be reimplemented + The driver will load automatically when appropriate hardware is detected in a system + Better performance than in userspace - Loading device firmware/calibration/configuration data is more complicated - The configuration is still device specific and needs to be passed from userspace Since I have zero experience with writing Linux kernel drivers, this is a bit of a tour de force. However, I have looked at similar drivers (linux/drivers/input/touchscreen/*i2c* are of particular interest), and I think it should be doable, even for a novice. I have collected two important bits so far: - The corresponding DSDT entry from my tablet - A header file containing the configuration data that was shipped with the Windows driver I also found the data sheet for the GSL1680/3680. It's marked as Release under NDA, so I'm not going to post it here. The filename is GSL1680.pdf, so you may easily find it yourself. The data sheet also mentions an application note and a configuration tool. Those would be interesting material, but I think the data sheet and existing driver code are sufficient write a new generic kernel driver. The things I want to figure out first, are: - Is there a vendor-supplied DeviceTree definition for a specific device, or does every manufacturer rely on hardcoded data in the driver? - What's the general structure of the firmware? Is it just a configuration file and calibration data, or does it contain actual program code? Can we split the two and use the code or part of the configuration for all GSLx680 devices? I wrote a driver skeleton that loads and matches successfully and gets the important data (I2C bus, device address and interrupt line number) from the DSDT passed by the kernel. I'm not doing anything with it yet, except logging. Interestingly, the IRQ number does not match what's written in the DSDT. There must be some kind of internal translation going on? See my fork of Joe Burmeister's sunxi-gslx680 project here: https://github.com/onitake/gslx680-acpi The DSDT and firmware header are in acpi/, the skeleton is in gslx680_ts_acpi.c. I also changed the Makefile to build for the local machine instead of cross compiling. Regards, Greg -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Further Allwinner misbehaviour.
Remember, this is a high priority reverse engineering project: https://www.fsf.org/campaigns/priority-projects/reverse-engineering Everybody must work on that. The linking of gpl libraries in the binaries must make the task easier. It's counterproductive try to hurt the image of the company in hope they will regret and do the right thing. They already have an $9 computer that is a tremendous marketing campaign. No way they will change their minds. 2015-06-30 5:34 GMT-03:00 Luc Verhaegen l...@skynet.be: On Mon, Jun 29, 2015 at 02:19:00AM +0200, Henrik Nordström wrote: tor 2015-06-25 klockan 12:13 +0200 skrev Luc Verhaegen: The bad copyright headers is just stupidity. The direct loading of non-LGPLed binaries into LGPLed code is very deliberate. And to my best understanding is not in any way a violation of the LGPL license. Care to explain what I am missing? (ignoring any past state of these files) If the code had been GPL licensed then sure. But this is LGPL with it's implicit linking exception. Yes, you are right. I always assumed that LGPL only worked upwards, but after a very thorough read there is nothing in the license that clearly defines this. It does however seriously push the boundary of derivative work, not only because it is being loaded into the LGPLed library and does not work standalone or with other software, but more importantly because this .so does not function without LGPLed infrastructure provided in the top level software. The line becomes very blurry here, and whether this is derivative work or not will probably differ upon which lawyer you ask. What is clear however is that Allwinner can no longer feign innocence, lack of information, lack of knowledge, lack of understanding or just plaing old stupidity. It clearly is very much aware of what its legal obligations are, and is very actively feeling for where those boundaries truly lie, and where the lines of the LGPL license become blurry. Allwinner is trying to get away with the maximum of what it thinks it can get away with, and nothing has changed. Allwinner has not learned a single thing, and still is actively hostile towards free software, and has no real intention of proactively working with the linux sunxi community and its customers. While we all knew that to be true, this action is solid proof to that end. It is time to extend the negative marketing campaign to some of Allwinners customers, and truly hit Allwinner where it hurts. Luc Verhaegen. -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/-YMdSF99yc0/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
