So I come to this thread to figure out why the kernel update is conflicting with the injection drivers package - only to see that daaaaamn things have progressed. Reinob's talking about actually possibly getting rid of BME as a practical possibility (one he's actually been doing right now). So reinob, you're extra-awesome.

To maintainers of this kernel, and anyone else involved in the making of the new modules and all the updates, you're awesome.

I do wish the changelog was included in the actual debian packaging, so when I'm installing the package through the package managers I can read these changes. I also wish it was stated immediately where the 'included-in-kernel-power-modules' injection drivers are located (like, I fail to see why pali didn't think to include that info in this post: http://talk.maemo.org/showpost.php?p...&postcount=445 - I figured it out by 'dpkg -L kernel-power-modules', but still). But those are minor grievances, and I am glad to see kernel-power-modules actually include the injection drivers now. On the other hand, my anal give-users-choices philosophy is kicking in and kinda wanting to argue that it would be better of users could choose to not have the drivers there unless they wanted them, but at the same time, I know the drivers are in /opt and the amount of space they take up is small anyway, so it's probably not a big deal to the vast majority of users. It's probably better for package maintenance logistics to have these modules in the kernel (power) modules package anyway.

- About replacing BME and the ACT-DEAD state -
I personally support leaving it in somewhere, and maybe introducing some way of checking/setting user preferences as to whether they want stock act-dead, framebuffer console, or normal boot (I think it's fine if this was in some obscure config file - others will code GUIs for editing these things if they wanted). I think you could accomplish this fairly easily with a shell script (/ addition to /sbin/preinit ) that, if state is ACT-DEAD, loads the minimum required drivers to power off the screen completely, unloads fbcon and dependencies if they're loaded, execute whatever the kernel-charging voodoo is needed, then upon detecting full charge, run 'shutdown', and there's your act-dead. Well, I guess normal act-dead leaves green LED on instead of shutting down, so do that instead, and add a 'shutdown after charge on act-dead' option for the shutddown version.

I would also argue for not worrying about console shell for those options because in my opinion the ideal boot console prompt would come in a single spot that all boot paths would go through - I personally like having my absurdly-early /sbin/preinit press-any-key-for-shell spot, which kicks in before it even checks the bootstate if I recall correctly, but for most users something later (when things are actually mounted) would be nicer.

@pali

So hold off on updating to kp51 then? just making sure the fix has not yet been uploaded

Now kp 51r1 is in extras-devel which seems working... I will create new thread about kp51

You can effectively eliminate act-dead by setting R&D flag '--force-power-key'.

This way whenever the N900 is booted it will always think it was because you turned it on as oppose to act_dead, recovered from crash etc.

Metalist, Pali has ALMOST eliminated the need for BME by writing a new kernel module that will take care of the USB charging controller. This used in conjunction with the bq27x00 module will allow for a BME free future.

kernel-power v51 (r1) is now in extra-devel. see thread http://talk.maemo.org/showthread.php?t=85665

Responding to this in the thread Pali just started, because it's more relevant to future development methinks.

- Edit - actually nvm: putting it in here, so as to not splinter discussion:

I think this only strengthens my argument for an act-dead functionally that's the same as now, for those users who like that functionality, but which has seperate confurable set of other choices. Afterall, for the typical user, enabling R&D mode is an inconvenient affair - the only on-device R&D mode changing programs are qwerty12's GUI one and my command-line one, both of which are available in only source code form right now (mine exists in compiled, old-and-flawed version, in one post, but meh). Plus, you then have to edit /sbin/preinit manually to disable keyboard flicker, which by default happens when R&D mode is on.

I can see plenty of users wanting a non-ACT-DEAD option, but not wanting to get their hands into the R&D Mode mes.

Okay, that's basically what I gathered, thanks for the confirm. I know in the past people like joerg have said that bq27x00 is a broken module in one way or another (a discussion that was always too technical for me to retain any of the details in the long-term): have the same disagreements been voiced with regards to this move?

@pali what does the charger driver do? im having trouble getting my usb port to recognize any charger (except for the nokia usb data cable). I have read in some threads that this can be fixed by flashing (as charging issues are often software related) any ideas?

I have already checked my usb port, it does not seem loose at all, I did however put some extra soldering to hold it down. But im still having the same issue. It does not want to recognize any cable at all (only the nokia one)

help?

kernel charger driver (which is disabled by default) do battery charging and vboost for usb host mode.

Hmm.. is KP51 from extras-devel the same one that you posted here? (http://talk.maemo.org/showpost.php?p...&postcount=445)

I'm using the latter, and as you probably know from my off-topic ramblings I can load and unload the module without a single problem.

Can you explain the bug? (if you have some additional information) I'll be happy to debug what I can..

That bug is already fixed in extras-devel. And pre release v51 is not same as v51r1 (it contains changes for new usb host mode)