Linux USB HID aansturen

[Verwijderd]

Hoi,

Ik ben opzoek naar iemand die mij kan helpen met wat info over het aansturen van een HID usb device onder Linux. Onder windows snap ik het allemaal.

Via google is er inderdaad veel te vinden, echter vele documentatie is niet compleet of heeft men het slechts over muizen en toetsenborden.

Enfin, wellicht dat er hier mensen zijn met ervaring. O ja, mijn HID device wordt wel al 'gevonden' onder Linux dus dat is niet meer het probleem, alleen de communicatie lukt dus nog niet.

Gr.
Jodocus

[DEVoTi0N]

Wat wil je dan aansluiten? Beschik dat apperaat niet gewoon over z'n eigen drivers?

[NMe]

Dat lijkt me ook wel eigenlijk. Praten met hardware is eigenlijk altijd hardwarespecifiek. Zit er geen voorbeeldcode bij de drivers van de het apparaat? Of als het apparaat zelfbouw is: welke chip gebruik je?

[Verwijderd]

Nee het apparaat is USB HID class. Deze worden onder Windows en Linux gewoon herkend. Dit is het voordeel hiervan...geen drivers benodigd ...

Maar dat wil nog niet zeggen dat je klaar bent, je moet er wel mee kunnen kletsen. Heb net iets gevonden van 'libusb' wellicht dat ik hier iets mee kan doen ? Enfin, ik ga gewoon verder met proberen

[eamelink]

Wat heb je dan voor device?

[Verwijderd]

Hoi,

'T is een USB IO interface. Heb deze zelf ontwikkeld en tja, uit de Linux hoek blijkt ook erg veel interesse te zijn ....dus nu bezig om dit ook onder Linux aan de praat te krijgen.

'k zit alleen nog met dat open source. Niet dat ik er een tegenstander van ben. 'T is alleen zo dat ik iets wil afleveren dat werkt en niet dat mensen er aan gaan sleutelen waarna ik daar support op moet leveren. Alhoewel er natuurlijk voordelen aanzitten. Enfin, eerst maar eens kijken of het allemaal lukt.

Gr.
Jodocus

[Zr40]

Als je software released onder de GPL, ben je niet verplicht om support te leveren, laat staan op aangepaste versies. Daarentegen is support leveren niet verboden.

[ Voor 3% gewijzigd door Zr40 op 05-04-2006 20:25 . Reden: Nadruk verplaatst van 'verplicht' naar 'niet' ]

[Verwijderd]

Het werkt Tja, libusb was achteraf eigenlijk niet helemaal nodig, maar was wel erg behulpzaam.

Zr40 schreef op woensdag 05 april 2006 @ 20:19:
Als je software released onder de GPL, ben je niet verplicht om support te leveren, laat staan op aangepaste versies. Daarentegen is support leveren niet verboden.

Daar heb je natuurlijk helemaal gelijk in. Maar wat ik me nu afvraag, stel ik maak nu dus een eigen implementatie van dit alles, waarbij ik dus slechts een gedeelte nodig heb. Alhoewel zoiets geen copy-past actie is, heb je wel gekeken naar hoe de open-source implementatie is gedaan. Volgens mij is dan mijn code niet open-source. Echter, er bekruipt mij dan ook wel weer een gevoel dat het niet helemaal klopt. En als dit zou gelden, dan kan elke fabrikant in principe op deze manier de GPL bypassen lijkt me. Enfin, het is niet zo dat mijn opzet is dat ik per-se niet opensource wil zijn, maar heb nogal wat vragen...wellicht maar eens google ...

Tja, 'k ben nog niet echt thuis in GPL land, maar zou graag hier wat meningen overhoren....hmmm, dit dreigt wel een beetje offtopic te gaan. Dus ik hoop dat ik toch even een paar reacties kan krijgen voordat ik met deze thread stop.

Gr.
Jodocus.

[Gerco]

Verwijderd schreef op woensdag 05 april 2006 @ 23:16:
Daar heb je natuurlijk helemaal gelijk in. Maar wat ik me nu afvraag, stel ik maak nu dus een eigen implementatie van dit alles, waarbij ik dus slechts een gedeelte nodig heb. Alhoewel zoiets geen copy-past actie is, heb je wel gekeken naar hoe de open-source implementatie is gedaan. Volgens mij is dan mijn code niet open-source.

Dat klopt, je code is alleen verplicht open source als je code uit een GPL applicatie kopieert en je applicatie gaat verspreiden. Je bent dus aan niemand iets verplicht als je je applicatie voor jezelf houd, of als je al je code zelf hebt geschreven. Afkijken mag daarbij gewoon vziw.

Echter, er bekruipt mij dan ook wel weer een gevoel dat het niet helemaal klopt. En als dit zou gelden, dan kan elke fabrikant in principe op deze manier de GPL bypassen lijkt me.

Het draait allemaal om de definitie van "afgeleid werk" in de GPL. Als je code zo erg lijkt op de GPL code dat je het zou kunnen beschouwen als afgeleid werk, bevind je je op een hellend vlak. Als je alles zelf hebt geschreven, maar gewoon wat ideeen hebt opgedaan in GPL code, is er niets aan de hand.

Enfin, het is niet zo dat mijn opzet is dat ik per-se niet opensource wil zijn, maar heb nogal wat vragen...wellicht maar eens google ...

GPL'en van je applicatie verplicht jou tot helemaal niets, maar het heeft wel duidelijke voordelen. Bijvoorbeeld dat je code door anderen opgenomen kan worden in de Linux kernel (als het een driver is). Anderen kunnen ook je code verbeteren en de GPL verplicht hen dan om die verbeteringen ook GPL te maken als ze die verspreiden.

Zo lang je je applicatie niet gaat verkopen is er, mijns inziens, geen reden om het niet GPL te maken. Het enige wat je ermee bereikt is dat mensen niet met je code aan de haal kunnen gaan en zeggen dat het van hen is. Maar dat kunnen ze ook niet als je de code voor jezelf houdt.

[Verwijderd]

Hee Gerco,

Thanks voor je reactie. Je hebt gelijk wat de voordelen betreft. Het is echter zo dat dit waarschijnlijk wel commercieel gebruikt gaat worden door anderen. En tja, dan is natuurlijk het probleem dat wanneer zij mijn ge-GPL-de code gaan gebruiken dat zij hun code ook weer van GPL moeten voorzien.

To be continued zullen we maar zeggen.

Gr.
Jodocus.

[Gerco]

Verwijderd schreef op donderdag 06 april 2006 @ 08:44:
Thanks voor je reactie. Je hebt gelijk wat de voordelen betreft. Het is echter zo dat dit waarschijnlijk wel commercieel gebruikt gaat worden door anderen. En tja, dan is natuurlijk het probleem dat wanneer zij mijn ge-GPL-de code gaan gebruiken dat zij hun code ook weer van GPL moeten voorzien.

Dat kan lastig zijn. Er is bijvoorbeeld al meerdere keren GPL code opgedoken in consumentenrouters. Die code (meestal van iptables) is dan dus ontrechtmatig gebruikt en je zou naar de rechter kunnen stappen. Dat kost echter een boel centen.

Als je dat soort dingen bij voorbaat al wilt voorkomen, moet je je code niet vrijgeven. Helaas is het in de linux wereld vrij ongewoon om closed-source te werken. Je kan het dan ook wel vergeten dat een distributie als Debian je programma gaat meeleveren.

Als dat allemaal niet van belang is, moet je gewoon de code voor jezelf houden. Helaas wordt closed source wel een beetje met de nek aangekeken in de "GPL wereld" en zal er waarschijnlijk wel iemand opstaan die een vrije driver maakt voor je device (als dat device populair wordt). Ik vraag me alleen af wat er zo speciaal is aan die code dat je die geheim wilt houden? Ik ga er vanuit dat je winst uit de verkoop van dat device gaat komen en dat je wilt dat zoveel mogelijk mensen het zo makkelijk mogelijk kunnen gebruiken?

Overigens... wat voor device hebben we het over? "Een I/O interface" zegt niet zoveel. Kun je er bijvoorbeeld je lampen, verwarming, koffiezet apparaat mee aansturen? Zo ja: Hebbe!

[ Voor 17% gewijzigd door Gerco op 06-04-2006 08:56 ]

[[ti]]

Als je toch graag je code open source wil maken gebruik dan in plaats van de ('virale') GPL licentie gewoon de BSD of zlib licentie. Deze licenties verplichten mensen die je code in commerciele producten willen gebruiken tot vrijwel niets, en conflicteerd ook niet met distributies als Debian die alleen maar 'echte' open source gelicenseerde producten willen meeleveren.

[Gerco]

ipv een BSD licentie kun je ook nog een dual-license hanteren.

Je geeft je code weg onder de GPL en verkoopt het ook nog eens met een minder beperkende licentie. Zo kunnen open source liefhebbers de GPL versie gebruiken en hardware fabrikanten kunnen dan een licentie van jou kopen en hoeven hun code niet vrij te geven.

Als je geen geld wil verdienen met je code en je wilt dat het commercieel ingezet kan worden zonder jouw toestemming of medeweten, kun je altijd nog voor een BSD licentie kiezen. Dan zijn bedrijven die jouw code gebruiken alleen verplicht om een melding daarvan te maken in een about box of andere copyright notice, verder niets. Het is maar net wat jij wilt dat er kan.

Er is veel keuze, dat is waar. Misschien moet je bedenken wat jij wilt dat er kan met jouw code en dan pas een licentie (of meer dan 1) erbij verzinnen. De makkelijkste manier is nog altijd om geen code vrij te geven en deze alleen te verkopen/geven aan hardware fabrikanten die jouw device willen produceren.

[ Voor 9% gewijzigd door Gerco op 06-04-2006 09:27 ]

[Verwijderd]

Gerco schreef op donderdag 06 april 2006 @ 08:52:
[...]

Dat kan lastig zijn. Er is bijvoorbeeld al meerdere keren GPL code opgedoken in consumentenrouters. Die code (meestal van iptables) is dan dus ontrechtmatig gebruikt en je zou naar de rechter kunnen stappen. Dat kost echter een boel centen.

Dat wil ik dus ook zeker voorkomen, ik vind het niet kunnen om credits te hebben voor het werk van anderen.

Als je dat soort dingen bij voorbaat al wilt voorkomen, moet je je code niet vrijgeven. Helaas is het in de linux wereld vrij ongewoon om closed-source te werken. Je kan het dan ook wel vergeten dat een distributie als Debian je programma gaat meeleveren.

Als dat allemaal niet van belang is, moet je gewoon de code voor jezelf houden. Helaas wordt closed source wel een beetje met de nek aangekeken in de "GPL wereld" en zal er waarschijnlijk wel iemand opstaan die een vrije driver maakt voor je device (als dat device populair wordt). Ik vraag me alleen af wat er zo speciaal is aan die code dat je die geheim wilt houden? Ik ga er vanuit dat je winst uit de verkoop van dat device gaat komen en dat je wilt dat zoveel mogelijk mensen het zo makkelijk mogelijk kunnen gebruiken?

Dat klopt, alles is er op gericht dat mensen het inderdaad eenvoudig kunnen gebruiken. Ik ben bang dat wanneer je dus mensen de source code gaat geven zij dingen gaan wijzigen. Hierdoor is het mogelijk dat het product niet meer goed functioneerd (ja, je moet alles afvangen...maar ja, er kan altijd iets doorheen glippen). En als mensen dus slechte ervaringen met het product krijgen, dat kan dat ook tenkoste van de naam van het bedrijf gaan. Nou ben ik geen miljoenen bedrijf dus dat zal allemaal wel meevallen, maaar ik wil er toch over nagedacht hebben

Een ander lastiger probleem is dat wanneer ik GPL spullen gebruik, en dus mijn software ook GPL moet zijn, en dat klanten die het product ook weer commercieel toepassen hun code OOK GPL moeten maken; nou daar zijn veel niet erg blij mee.

Overigens... wat voor device hebben we het over? "Een I/O interface" zegt niet zoveel. Kun je er bijvoorbeeld je lampen, verwarming, koffiezet apparaat mee aansturen? Zo ja: Hebbe!

Ik wil er niet te veel hierover kwijt, aangezien ik dus probeer een bedrijfje op te zetten hiermee kan dit worden opgevat als reclame...en daar wil ik GoT liever niet voor gebruiken.

Dus even heel kort. Het is een 16 bits USB interface kaartje. Heeft dus 16 individuele in- en uitgangen en is onder Windows en Linux plug-and-play. Dus heeft geen driver benodigd. Uitgangen zijn TTL/CMOS. Je kunt er vanalles aanknopen. In Belgie is het toegepast in een domotica omgeving. In Duitsland gebruiken ze om vanuit een centrale computer een alarm aan te sturen. Dus de sky's the limit ...En voordat er weer 'slimme' mensen 'slimme' opmerkingen gaan plaatsen...ik weet dat het niet uniek is. Ik onderscheid mij vooral door het gemak in het gebruik ervan...echte plug-and-play dus ...

Mocht je nog meer info willen hebben, geen probleem maar stuur me even een prive-emailtje en dan stuur ik je de link naar mijn website.

UPDATE: Lachen, de software die ik gebruikte blijkt LGPL te zijn niet GPL.... dus dan heb ik helemaal geen probleem.

[Gerco]

Verwijderd schreef op donderdag 06 april 2006 @ 13:02:
Dat klopt, alles is er op gericht dat mensen het inderdaad eenvoudig kunnen gebruiken. Ik ben bang dat wanneer je dus mensen de source code gaat geven zij dingen gaan wijzigen. Hierdoor is het mogelijk dat het product niet meer goed functioneerd (ja, je moet alles afvangen...maar ja, er kan altijd iets doorheen glippen). En als mensen dus slechte ervaringen met het product krijgen, dat kan dat ook tenkoste van de naam van het bedrijf gaan.

Ik denk dat dat wel meevalt in de linux community. Men weet dat als je aan de code gaat klooien, het weleens kapot zou kunnen gaan. Dat risico wordt gewoon genomen. Als je geen vrije driver released, zullen er waarschijnlijk toch wel een paar mensen proberen er 1 te schrijven als je device voldoende populair wordt. Als dat lukt, zullen nog heel erg weinig mensen jouw meegeleverde driver gaan gebruiken (alleen op Windows waarschijnlijk). Dan heb je helemaal niets om je zorgen over te maken, hooguit dat je de naam van de zoveelste "paranoia hardware bouwer die zijn bedrijfsgeheimen in drivers stopt" krijgt.

Een ander lastiger probleem is dat wanneer ik GPL spullen gebruik, en dus mijn software ook GPL moet zijn, en dat klanten die het product ook weer commercieel toepassen hun code OOK GPL moeten maken; nou daar zijn veel niet erg blij mee.

Hangt er maar net van af wat jouw software doet Als het een library is waarmee gelinked moet worden, hangen je commerciele partners ja. Dan zou je BSD of LGPL moeten gebruiken.

UPDATE: Lachen, de software die ik gebruikte blijkt LGPL te zijn niet GPL.... dus dan heb ik helemaal geen probleem.

In dat geval kun je er dus zelf voor kiezen om de source van je spul vrij te geven. De source van de LGPL software moet je natuurlijk wel meeleveren als je die distribueert, maar je eigen source (het afgeleide werk) dus niet.

Even voor de duidelijkheid: Waar praten we over? Een driver? Een library? Een CLI/GUI interface om je device mee aan te sturen? Het maakt nogal wat verschil wat het is om te kunnen zeggen of het zinnig danwel noodzakelijk is om de source mee te leveren voordat de Linux community er brood in ziet

Als je device ook bruikbaar is zonder die code (er is geen driver nodig zeg je), is het natuurlijk al een stuk minder noodzakelijk dan wanneer het echt nodig is (zoals met een driver).