[chazzek]

I quickly ported that python code to C, cleaned it up a bit, added meklort's inb/outb functions, and tried it. I get a segfault, so I guess inb and outb are privileged and only run in kernel mode. I'm not quite sure how to make a kext, but I can post the code if someone else wants to try.

[meklort]

Originally Posted by chazzek

I quickly ported that python code to C, cleaned it up a bit, added meklort's inb/outb functions, and tried it. I get a segfault, so I guess inb and outb are privileged and only run in kernel mode. I'm not quite sure how to make a kext, but I can post the code if someone else wants to try.

Yes, you have to have kernel mode privs.

If you want to put the code up, I'll write a quick kext over the weekend.
Oh, and the parameters for inb and outb in c are swapped from the parameters in python

[chazzek]

Here it is. I noticed the inb/outb parameter ordering while I was reading the code. The only thing I'm not sure about is whether all the port polling will still work here, but once the kernel mode side is working it can be tweaked.

[discmeister]

I just wanted to offer my thanks and appreciation for those who are working on this. Being able to switch the BT on and off from within Mac OS X is one of precious few areas where the Mini 9 falls short. It's be awesome to have a fix.

I'm afraid I'm not much of a coder, but I have BT on my MIni 9 (10.5.6) if you need me to try anything.

Discy

[tetany]

Originally Posted by discmeister

I just wanted to offer my thanks and appreciation for those who are working on this. Being able to switch the BT on and off from within Mac OS X is one of precious few areas where the Mini 9 falls short. It's be awesome to have a fix.

I'm afraid I'm not much of a coder, but I have BT on my MIni 9 (10.5.6) if you need me to try anything.

Discy

I would also be happy to try this as well. I miss my bluetooth stuff! This is an awesome forum with amazing coding experts.

[meklort]

The wireless manager is currently on hold. At the moment, when you run it it freezes up the computer. This is probably because it's writing to the Embedded Controller ports (I believe), which I also being used by another kext. This will probably cause a conflict and freeze the system as it does currently. It may be possibly to use the AppleACPIEC kext (by calling the readEC and writeEC methods) to control the wireless, however it will use undocumented methods (read: no headers / source is available).

If someone wants to work on it, the source is in google code.

[atm153]

Ha, I knew I should have looked into this before I started digging around in code, I should have known someone much more skilled than I would have made an attempt by now :P
What kext is using the EC?

[ehunt123]

I'm unfamiliar with how OSX does the airport control because its normally handled by the os, with locked hardware, so its not like Linux where you can get deep into the code.

I'm gonna speculate here, knowing a little about code and kernel development but am sure this explanation has flaws in it, as I know how challenging hardware development can be. Some of this did come from a friend who does hardware development on embedded linux platforms, so I hope its at least informative and someone more knowledged can fill in the blanks.

From what I know with having a Dell Inspiron 10 years ago in Linux, software and hardware methods don't always work because of access to the hardware and drivers. The hardware method would be having a physical switch, either premade (lots of laptops have these now) or doing a little resistor mod, so that power can be 0 or 1. The driver has to support changing states, as I have had quite a few experiences when the power state changing not being something the kernel driver is able/set/properly handling will cause a panic. Other way around this is (and most companies do this, I assume, because its easier/cheaper) is a hardware button generating an interrupt that causes the power to go off, below the user layer but at the kernel layer. PortIO is a framework that I have compiled on 10.6 and know the MSI guys are using to help control things like this.

When you have a hardware switch that requires the hardware to do something, such as turn the speakers off, turn power off, disable keyboard backlighting, etc, you normally have to have raw IO access because its got to be handled by the machine itself. I am unaware of macbooks normally having this level of control because apple embeds this into the kernel/bootloader (like booting with 6+4 down). you obviously also have quite a bit of control over the machine, so entering a wrong command will normally result in a panic.

I'm assuming DSDT normally remaps this "built in" functionality to normal keys. Even though you're on a different machine, if the built-in kernel is still thinking its on a mac, ergo it has the functionality for things like backlit keyboards, controlling wireless power, etc.

On macports, there is an airport command that did most/all but power up and down, I think. I would assume that power is part of this, but am not sure if this would perform the same function as turning the power off.

Into software: you can turn the "functionality" off while keeping the keXT there. think mute on a speaker. functionality is all still there but is in some "hibernate mode". I recall a hack a few years ago to disable the macbook camera because people hated the security potential. I don't recall apple offering a way to "turn it off" at all, and assume someone used Amit Singh's LCD code to hack the power on w/o the LCD light. The "method" did nothing more than chmod the keXT so the machine would have no access to the hardware. I assume doing a kextload/kextunload worked fine, but its kinda annoying when you don't have this access.

I have been looking into PortIO but do not know how to probe the registers, nor am good enough to grab the developer docs for the wireless card onboard and translate this. That would be a great option since raw hardware access, to me, was one of the last frontiers in my Linux days of when you really lost no functionality by not running Windows. I know airport can be turned "off" via OSX, where the driver is not listening/sending, and assume this is probably the safeway

[unclemiltie]

Originally Posted by meklort

I probably wont start working on it untill next week at the earliest.
and since I don't have bluetooth, it may by iffy as to getting it working (atleast easily).

You really should go on ebay and buy the internal bluetooth modules, that way you'll have everything in your systems that you need to do the testing.

If you don't have the cash, send me a PM with an address and they'll be on their way.