After adding the settings listed by einfo to xorg.conf and restarting X11, the touchpad does not work and X.org gives the following error: (EE) LoadModule: Module mtrack does not have a mtrackModuleData data object (EE) Failed to load module "mtrack" (invalid module, 0) (EE) No input driver matching 'mtrack' System is ~amd64, up2date as of this writing, ie. xorg-server-1.10.1.901, gentoo-sources-2.6.38-r5. Notebook is a Macbook Pro 8,1 (13" early 2011). Don't know if it's related, but trying to cat /dev/input/{event8,mouse0}, which represents the touchpad, gives me a "no space on disk error". Reproducible: Always Steps to Reproduce: 1. emerge xf86-input-mtrack 2. add settings to xorg.conf 3. restart X11 Actual Results: Touchpad does not work at all Expected Results: Touchpad should work
After building the git-version of mtrack and trying that, I get a "slightly" more useful error-message: (EE) xf86OpenSerial: Cannot open device /dev/input/event9 No space left on device. (EE) mtrack: cannot open device (EE) Couldn't init device "bcm5974" So, as I thought, this is related to the "no space"-error. But I don't know, how to get rid of that :/
I'm suspecting that there is something wrong with -1.10.1.901 server. I was able to use this driver on -1.10.1 and now I get the same error o -1.10.1.901.
(In reply to comment #2) > I'm suspecting that there is something wrong with -1.10.1.901 server. I was > able to use this driver on -1.10.1 and now I get the same error o -1.10.1.901. I'll try a downgrade later, for now I'm off to bed. If you read in the meantime, maybe you can have a look at the following bug and tell me if it's related or where it could come from: https://bugs.gentoo.org/show_bug.cgi?id=367597 thanks.
I downgrade xorg-server, re-emerged all drivers, no change. Since you seem to already had it running at least once, I'd like to request a copy of your kernel-config - along with any stuff you might have done, to get the touchpad work in the first place, if any. I'm still not ruling out a misconfiguration or kernel-bug, but since this is my first Macbook, may I just overlooked something.
I ran it for a while, when the driver moved from an overlay to ~amd64 in mainline, it started having this same error.
Just to let you all know, I fixed the device being completely unusable at all: https://bugs.gentoo.org/show_bug.cgi?id=367597 As far as mtrack goes, I can't get it to load, doesn't matter if I use the latest ~amd or amd64 stable xorg-server.
As a further update, I couldn't get the packaged version in portage to run, no matter against which version of xorg-server. So I checked out the dev-branch, built and installed that and it works like a charm.
I've commited -r1 version to portage. Could you try it? (Original package doesn't export the data variable. so strip drop it)
(In reply to comment #8) > I've commited -r1 version to portage. Could you try it? > > (Original package doesn't export the data variable. so strip drop it) That gives me: (EE) mtrack: cannot configure device (EE) Couldn't init device "bcm5974" Then falling back to evdev. Maybe there's just new code in the dev-branch, needed for the new Macbooks to work(didn't check the commit-logs, yet)?
I was able to briefly reproduce the issue and confirm that submitted patch fixes the issue. I've added it to the official dev tree. Manu, I've not done anything that should have caused this to work in dev where master wouldn't. Could you attach your full xorg log? Itappears to be different issue now.
By the way, I believe I know what caused the original issue. Prior to today there was no autoconf/automake in my package. I added all of that to the dev tree today. Not coincidentally, a patch was submitted with the original ebuild that added autoconf/automake to the package. They both caused the same issue, and the fix was the same in both instances.
Created attachment 274443 [details] xorg.log As requested, here you go :)
Manu: Doing a simple gzip -d on that file gives me gibberish, even though file reports it as a gzip compressed file. What's up with that?
Ryan, sorry. I just verified this, it's not gibberish, it's gzipped again. I didn't do this, at least I don't remember, maybe the new bugtracker compressed it again? Anyway, just gunzip the resulting file once again, works here.
The driver loaded properly for device /dev/input/event8. See lines 388 to 424. The InputClass will attempt to match other devices as well and fail on those, but it succeeds on the above, which should be the proper device.
Yep, it's the proper device. Just been a little puzzled that though it works, still another error occurs. Maybe that can be surpressed?
You just need to change the InputClass to filter on /dev/input/event* devices only, or use a device section specifying the device file instead of an inputclass.
Alright, good enough for me. Thanks :)