search

glorang / nwfermi

NextWindow Touchscreen on Ubuntu 22.04
MIT License
21 stars 4 forks source link

Kernel Upstreaming #7

Closed alexhorner closed 1 year ago

alexhorner commented 1 year ago

Is it likely that you will ever seek/be able to legally upstream this into mainline, so that it is part of the official kernel tree?

DaveJamieson commented 1 year ago

Not likely to be honest sorry.By the time I gain the skills to accomplish that all the machines that rely on it will probably be parted out. I can delete it if necessary.. -------- Original message --------From: Alexander Horner @.> Date: 8/05/23 03:01 (GMT+12:00) To: glorang/nwfermi @.> Cc: Subscribed @.***> Subject: [glorang/nwfermi] Kernel Upstreaming (Issue #7) Is it likely that you will ever seek/be able to legally upstream this into mainline, so that it is part of the official kernel tree?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

alexhorner commented 1 year ago

Not likely to be honest sorry.By the time I gain the skills to accomplish that all the machines that rely on it will probably be parted out. I can delete it if necessary.. -------- Original message --------From: Alexander Horner @.> Date: 8/05/23 03:01 (GMT+12:00) To: glorang/nwfermi @.> Cc: Subscribed @.> Subject: [glorang/nwfermi] Kernel Upstreaming (Issue #7) Is it likely that you will ever seek/be able to legally upstream this into mainline, so that it is part of the official kernel tree? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.>

No worries! I am not at all suggesting it needs deleting, just wondered if it was a goal at all!

glorang commented 1 year ago

@Dave-ctr did you intent to reply to something/someone else ? I have the impression your reply is not related to the nwfermi project or some context is missing.

@alexhorner No, this will never be part of mainstream kernel. For proper functioning you need the closed source user space daemon "nwfermi" as well.

alexhorner commented 1 year ago

@Dave-ctr did you intent to reply to something/someone else ? I have the impression your reply is not related to the nwfermi project or some context is missing.

@alexhorner No, this will never be part of mainstream kernel. For proper functioning you need the closed source user space daemon "nwfermi" as well.

Hey @glorang, Oh, I thought that might have been you via email reply, nevermind!

Well, the driver itself, would it be possible to upstream it? I would imagine with a little effort, it would be possible to cleanroom rebuild the userspace daemon and have that be open source.

glorang commented 1 year ago

No, sorry. There is no source code available of the user space daemon and without it the kernel module will not work (or is at least pretty useless), I don't think they'll ever accept. Or what do you mean by "cleanroom rebuild the userspace daemon" ?

Most feasible would be to package it again in Ubuntu repositories, but not sure it's really worth the effort.

alexhorner commented 1 year ago

By this I mean someone completely building a new userspace daemon which replaces the closed one, by replication if the existing one's capabilities without disassembling it at all. -------- Original message --------From: Geert Lorang @.> Date: 09/05/2023 15:04 (GMT+00:00) To: glorang/nwfermi @.> Cc: Alexander Horner @.>, Mention @.> Subject: Re: [glorang/nwfermi] Kernel Upstreaming (Issue #7) No, sorry. There is no source code available of the user space daemon and without it the kernel module will not work (or is at least pretty useless), I don't think they'll ever accept. Or what do you mean by "cleanroom rebuild the userspace daemon" ? Most feasible would be to package it again in Ubuntu repositories, but not sure it's really worth the effort.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

glorang commented 1 year ago

No, sorry, not gonna happen from my side. That's an awful lot of work for which I don't have time nor the skill, sorry.

You'd need to be an expert in touchscreens and X development with a lot of time just to "open source" a handful of screens that were in existence 10-15 years ago. It's really not worth effort I think.

alexhorner commented 1 year ago

No, sorry, not gonna happen from my side. That's an awful lot of work for which I don't have time nor the skill, sorry.

You'd need to be an expert in touchscreens and X development with a lot of time just to "open source" a handful of screens that were in existence 10-15 years ago. It's really not worth effort I think.

I'm not suggesting you do it, someone else can, hell maybe I might take a shot at it at some point for giggles. This was more an issue of "could this even be upstreamed" rather than why it isn't already

glorang commented 1 year ago

Yeah sure :-) It might be something fun to try out yes. I'm not an expert in X and/or touchscreens but I believe the most ideal situation would be that all functionality of the nwfermi daemon is ported to the kernel driver which then implements the evdev interface. Like this there are no dependencies and then there would be a chance you can get it included in upstream kernel.

There was another guy (someone smarted than me) who already did part of this work for Android (so it should be compatible). If I find back the link I'll post it here. Update: https://groups.google.com/g/android-x86/c/5_J7-AuXWms/m/oEAZN5HQBwAJ it was this one, but this still depends on nwfermi_daemon.