Description of problem: gpsd doesn't see Garmin USB devices without this module. Currently this means nothing works (gpsdrive, tangogps, etc.) without the garmin_gps module. Can we please have this back, if it still works, until such time as gpsd is updated to use libusb? Version-Release number of selected component (if applicable): All of rawhide releases since .108
I'm building a test kernel to make sure this works now. I'll turn it on once I'm certain that it builds properly on all appropriate arches.
Thank you. If you need a X86_64 tester to make sure the module works, I am such a person. (I can test i386 too, but I only have a few of these left.)
Thank you, I'll post the kernel when I have it together. I've also got a GPS 60 as well as 32 and 64 bit hardware .
x86 an x86_64 kernels built here, If you want to confirm that they work properly, I'll check this change in. Thanks! https://koji.fedoraproject.org/koji/taskinfo?taskID=938216
I have not tried i386 due to time constraints today. However, I did do x86_64. It seemed to work well here. Thank you.
commited to rawhide. Thanks!
Turning it on, though, means that any app which is doing the right thing and using libusb fails to work unless you remove the module first or blacklist it. And we ship a couple of things in Fedora which do that (garmin-sync for one)
(In reply to comment #6) > commited to rawhide. Thanks! Rawhide is now F-11.
yeah, but not all apps do the right thing (like gpsbabel), and they're important. And its easier to blacklist a module then rebuild a kernel
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Are we going to see this in F10?
I would also like to have this back in F10... Thanks
Are we just doing a voting poll or is someone actually working on it? *smile* I'd prefer to see programs like gpsd updated to use the new tech. But then this garmin_gps driver should be added back for the software that hasn't caught up yet. At least in my opinion. So you got my vote to add it back too.
For those we cannot wait, here is how I proceeded in order to build a custom kernel to support gps_garmin on Fedora 10 (I thought that it may be useful in this thread, where everybody tends to end up): - in general, follow the instructions here: http://fedoraproject.org/wiki/Docs/CustomKernel - when generating the config, add the option CONFIG_USB_SERIAL_GARMIN (as module, to be able to unload it later when using incompatible tools) In the graphical kernel config editor it can be found under: Drivers/USB support/USB Serial Converter support/USB Garmin GPS driver. (that was the hardest part to find this ;) - in order to have the kernel-firmware RPM: Modify kernel.spec %define with_firmware %{?_with_firmware: 0} %{?!_with_firmware: 1} instead of %define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0} (thanks to http://forums.fedoraforum.org/showthread.php?t=209989) Execute rpmbuild -ba kernel.spec --target=i686 Built on a F10 x86_64, tested on a F10 i686 (Samsung NC10 netbook). Tested with gpsd and xgps (yum install gpsd-clients): gpsd -n -N -D 2 /dev/ttyUSB0 (as root) I am not a kernel building expert so there may be better ways but I hope it helps. (reference: http://www.argeo.org/mediawiki/index.php/Fedora#Add_Garmin_GPS_support)
Created attachment 335226 [details] tar file that can be used for out-of-tree build of kernel module You can avoid having to do a full kernel build, by taking the driver out of the sources and building it as an out-of-tree module. I'm attaching a .tgz file that contains simply the c file and a Makefile. You need the kernel-devel RPM installed, but apart from that, it's simply make + make install. Advantages: much faster build + you can stay with the default kernel that Fedora ships. As long as the file doesn't change in the kernel (unlikely), you can keep using it by rebuilding it after each kernel upgrade. If the file would change, simply take the new file out of the kernel sources and replace.
By the way, I tried making a kmod RPM (or even akmod) for this, but didn't really succeed due to lack of documentation. Maybe somebody else knows how to do that?
I actually tried the communication to the GPS now, using the module built as an out-of-tree module, but the driver doesn't seem to work anymore. I'm getting the same problem as reported in this mail: http://kerneltrap.org/mailarchive/linux-usb/2008/11/16/4135424 But it seemed to work for Mathieu? (I'm also on an x86_64)
Retargetting to rawhide as it still exists there.
The only solution that would be easy to implement would be to build the module but blacklist it so it doesn't interfere with apps that use libusb.
Chuck, that would be great and indeed a pragmatic solution! Any chance to have it in Fedora 11? (18 days before, I don't have that much hope...)
So, I'm not sure why this got reopened. The appropriate config option is on in cvs for rawhide, and has been since last november. The module builds appropriately, so it should be available in F-11. I can turn it on for F-10 if you all like, or We can move this bug to the modules-utils package to have garmin_gps blacklisted by default. But its not really clear to me what the desire is here.
For me personally, I would like to have this turned on again in F-10, because I need it to be able to use my GPS in Garmin's MapSource application via wine. If it needs to be blacklisted by default because of possible interference with another driver, no problem. The point is that there should be a way in F-10 to use the driver (which would then be by un-blacklisting it) without recompiling the kernel. Thanks in advance!
I support Peter proposal: building a kernel is fun but uncommenting (or for that matter, manually loading) kernel modules is much practical, especially when you routinely switch between some applications which require the module and others which are incompatible with it.
done, commited the config change to F-10.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Is this now supposed to be present in the latest F-10 kernel? It doesn't seem so. The config change for F-10 was reportedly done in May, but does it still need to be pushed to the official kernel for F-10? I don't know much about the procedures at Redhat/Fedora...
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
These appear to be included now in the kernel. I am going to mark this closed in 3 days if no one else needs it open.
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.