yashsingh1/xdaforums huggingface dataset:
[Nexus 6  Original Android Development] PerfectSlayer:
AP is still quite serious ;)

http://www.androidpolice.com/2015/0...t-tap-to-wake-is-now-a-setting-you-can-tweak/
[Nexus 6  Original Android Development] Yank555:
N9 always had it, N6 well never enabled ... So maybe they just allow you to disable it on the N9 if you want to save some more juice.

I don't need in on my N9, I have a flipcover, the device turns on when I open the lid and goes to sleep when I close it, so dt is nowhere userfull on that device for me.

JP.
[Nexus 6  Original Android Development] PerfectSlayer:
Yes, that's the goal. As said, they don't plan to enable it on other device.

Nevertheless, it could have been a good reason to add the setting in Slim.

(Personally, I don't use it at all on any device so it will not miss me ;))
[Nexus 6  Original Android Development] Yank555:
ROM Update

Tiny update again, includes :

- added heads up global switch (to disable headsup completely, on request)

- activated Google's dt2w by default for now (drain / usability test)

- headsup snooze fixed (Dankoman)

As usual, ROM download links can be found in my OP in the Builders Collective, post 14.

JP.

PS: build is uploading on both servers.
[Nexus 6  Original Android Development] niv3d:
So r6 is out lmbo....
[Nexus 6  Original Android Development] Yank555:
One step at a time, merging r5 proves to be more or less a nightmare ... and r6 just dropped ;)

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] danarama:
What? Nooooooo. Why? It's rubbish. One of the things i like about this rom is that this is not enabled by default. Its unreliable.

I vote make it a flashable extra so those who control it through proper kernel methods can continue without interference
[Nexus 6  Original Android Development] niv3d:
Oh no rush Yank! I was just laughing because Google started nightlies again.
[Nexus 6  Original Android Development] x111:
So cool that it activated right out of the custom box.

But would be nice to see this option in the settings.
[Nexus 6  Original Android Development] Yank555:
OKOK, you win, I'll switch that back right away :D

I was just too lazy to reflash the kernel :angel:

Btw, if you switch kernel, it shouldn't matter, though, it's not the ROM auto-activating it, just my kernel config script.

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.

---------- Post added at 07:34 AM ---------- Previous post was at 07:34 AM ----------

Yeah, and they do rebase in between, so they keep it 'interesting' the merge ;)

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.

---------- Post added at 07:35 AM ---------- Previous post was at 07:34 AM ----------

Sinve this is kernel dependant, it makes little sense to have it in the ROM :(

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] wiseguyy:
Link to Hells Core?
[Nexus 6  Original Android Development] skidaway:
Blog here:

http://hc-kernel.blogspot.ch/

G+ community here:

https://plus.google.com/communities/115269166678032690242
[Nexus 6  Original Android Development] Yank555:
OK, so I've been testing this for the day, since I wondered if it had been improved in M kernel sources ...

Not really, it still feels buggy, or unreliable ... BUT ... because there's a BUT ... as always :cowboy:

First I noticed, that when I tripple-tapped it worked more often, likely because it only registered two of the 3, so I started double-tapping slower.

And I managed to have it work cosistently, if I don't double tap too fast, like tap ....... tap rather then tap - tap, then it works all the time.

No idea if this is just me getting wonky or it's really the case.

Anyhow, it'll be out as default enabled with the next update, due sometime tomorrow evening I think.

Though, as I said, if you run a different kernel, shouldn't matter, as it's a pure kernel thing I changed.

JP.
[Nexus 6  Original Android Development] PerfectSlayer:
Ok. So what will be the procedure to re-enable it to git it a try?

---------- Post added at 01:34 PM ---------- Previous post was at 01:31 PM ----------

Didn't you say previously it is a feature of thebase kernel?
[Nexus 6  Original Android Development] Yank555:
You'd need to change one line (or three to be clean) in /system/etc/init.yank555.lu.kernel.sh, from :

# - [COLOR="Red"][B]Disable[/B][/COLOR] d2tw
echo "[COLOR="Red"][B]OFF[/B][/COLOR]" > /sys/bus/i2c/devices/1-004a/tsp
chmod 444 /sys/bus/i2c/devices/1-004a/tsp
echo `date +"%F %R:%S : Double-tap to wake [COLOR="Red"][B]disabled[/B][/COLOR] and userspace access locked down."` >>$log_file

to :

# - [B][COLOR="Red"]Enable[/COLOR][/B] d2tw
echo "[B][COLOR="Red"]AUTO[/COLOR][/B]" > /sys/bus/i2c/devices/1-004a/tsp
chmod 444 /sys/bus/i2c/devices/1-004a/tsp
echo `date +"%F %R:%S : Double-tap to wake [B][COLOR="Red"]enabled[/COLOR][/B] and userspace access locked down."` >>$log_file

Yes it is, all kernels do have the code, and it's disabled by default I think.

But if you go to a different kernel, and it brings its own ramfs (9 out 10 do), that init script is not getting run at boot anymore, hence it will stay disabled.

But as a switch in the ROM, it sould only be availabe for shamu (overlay in device repo, but for just 1 device...), and this could conflict with other wake-gesture coding in the kernel, as it will then have both, and only the generic will be switched.

JP.
[Nexus 6  Original Android Development] Yank555:
Gave a look if it would be possible to change this "delay" to allow for faster double-tapping, or make it user configurable.

But from what I saw in the code, looks they have embedded the pattern in the firmware, the driver will just receive a message and if it's that message, it wakes the device.

So it is what it is ...

JP.
[Nexus 6  Original Android Development] knightjs1:
WiFi calling

Just curious. Been running Slim over the years from galaxy s2, s4, oneplus and now my shamu. I went back to stock for the WiFi calling feature as I'm on T-Mobile. Seeing Google add that feature to M as well as latest r5, will Slim pick it up? I'm seeing some custom roms with it but not all. Yank, can you chime in?
[Nexus 6  Original Android Development] Blaiser47:
What about implementing flar2 's gestures? They work very well in my experience.
[Nexus 6  Original Android Development] Yank555:
Well in essence, could be an option, although I've never been a big friend of any such solution, because it will drain, may be little, may be more (like on hammerhead) ...

This implementation should/could be battery friendlier than any in-kernel as it seems to be handled parly by touchscreen firmware, which an in-kernel coded solution won't.

Still not sure where I will go with this, but it's just a tiny thing eventually, since there are valid kernel options on xda which cover these topics ;)

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] danarama:
Hammerhead drains because the power for the digitiser is not isolated from the LCD unit, so to have any double tap to wake etc, you're powering both. Not the case with shamu.

On Shamu, the drain from the elementalx gestures is so minute, you probably couldn't even calculate it.

That said, if someone wants elementalx gestures, why not use elementalx? It's a great kernel
[Nexus 6  Original Android Development] Yank555:
I know, that's what I meant when mentionning hh, I tested it back then, total nogo noway, esp. not with its tiny battery ;)

I'd expect stock dt2w to use potentially less in certain use patterns in that one tap (like phone put in your pocket, or carried in your hand) will not wake a cpu as the detect "double" seems to be handled by firmware, in conventional dt2w you need to set the timestamp, tap position and tap-count so you can compare if a subsequent tap happened within the given timeframe around the given position.

That setting a timestamp and checkimg vs. a first means executing code, so waking a CPU to execute it.

I coded touchwake back then for Note 3, I have a good idea of what it involves ;)

As said, on shamu it's not much, but then again it's not nothing, and it's the sum of not much that eventually makes a diff ;)

And I totally agree with your conclusion, those kernels are all there to be used if they fit one's show :D

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] _Garry_:
Just a small question yank.

Does your slim-build/kernel support "f2fs"?

When yes, which partitions? Cache/System only?

Sent from my Nexus 6 running latest SlimRom
[Nexus 6  Original Android Development] Yank555:
Nope, not supported in my kernel. As for partitions, from what I gathered, system is the most tricky one to convert, maybe not really the most useful, if the biggest benefits are in writes rather than reads (dunno, not that I explored the topic too deeply) ?

"f2fs" is not worth the fuzz imo (or still not at least yet), it may be interesting as an exploration kind of thing (to do it because you can), but the effort outweighs the benefit in real life use imo (move back on forth the data to reformat, potential hickups with lack of support, specific recovery etc. etc.), too much fuzz for me.

Real life use, I don't think devices are that I/O intensive to really make a noticable difference (we're not talking storage systems hosting multi user DBs or such, where I/O is THE bottleneck).

As such I never cared to include it in any of my kernels, nor add whatever support would be needed (ramfs, more ?) in the ROM (base Slim may also have it, never looked).

I gave it a quick glance when the hype started back then, but never looked back tbh.

JP.
[Nexus 6  Original Android Development] danarama:
Completely agree.

Only beneficial partition to do is /data, and as you say, it's not even really noticeable and all the effort you have to go to to maintain f2fs through flashes and upgrades, totally not worth it.

Though easy to achieve to get it into a build for a user, unpack ramdisk and change fstab to be f2fs instead of ext4, thats literally it... But yeah, it gets annoying having to do that to each kernel/ rom version you want to flash.
[Nexus 6  Original Android Development] _Garry_:
Well, I used slim with f2fs support in my old s2/note2 days. The benefit for "me" was perfect.

And for SlimLP I was wondering how it would perform with our shamu-device. Would it perform well enough to be thought about.

Or is it just not worth?

I don't mean an improvement of around 5%.

IMO its only worth when it goes +10%.

When I remember correct, for S2 and Note2, f2fs was used for cache, data and system. There was a long discussion which gave the most improvements: cache&data or cache&system? Well I had best improvements when all 3 were used using f2fs.

But I guess depending on "how" your phone is used the result differs much.

Sent from my Nexus 6 running latest SlimRom
[Nexus 6  Original Android Development] Yank555:
It all depends how you look at it. 10% in pure I/O may be possible, maybe a lot more or less, no idea.

But when you 'wait' on your device, that's not necessarily because you wait on I/O, so "lags" caused by I/O waits are only some, but far from all those lags.

So in everyday usage, getting 10% in 50% of the cases end up being a 5% improvement ON LAGs, not overall, but I don't think shamu lags that much, so the felt improvement will diminish the lesser the device lags, except if the only lags left would be I/O, which I'm not convinced of.

That's also the difference between an I/O benchmark and real life use.

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] danarama:
Yea but the s2 was a special case where they had to invent f2fs because the i/o on their implemented file system was so bloody poor. They made a mistake with the s2 and f2fs was the fix, but put it in place on a device that never had the s2's poor performance, it makes very little difference.
[Nexus 6  Original Android Development] knightjs1:
Waste of your time

I guess I'm the only Slim user who uses T-Mobile WiFi calling. I won't ask about it's implementation any more. Thanks to all who responded.
[Nexus 6  Original Android Development] Yank555:
Didn't someone report he had it working ?

I can't test anything, there's neither tmo nor any wifi calling available here (except VoIP SIP client, which works).

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] hlxanthus:
Don't give up on WiFi calling. A few roms have added it so it will come eventually. Please remember, yanks is building unofficially for us and his time is limited.
[Nexus 6  Original Android Development] Yank555:
I thought that it worked given the use of a specific (not latest) radio...

My time is indeed limited, yesterday and today = 0 :(

And chasing sth I can't test myself isn't an easy thing ... because it's very timeconsuming :(

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] Smallsmx3:
I'm no dev but I keep up on allot of threads, I've heard r6 includes the branch that was missing for WiFi calling. I don't what bits are needed kernel side, but there are plenty of kernels that work. I'm on tmo and WiFi calling is something I've been waiting for. I went back to stock recently to see what I was missing, the only thing I'm missing are. Some features, long story short I've been waiting for Slim to finish catching up. I know the devs have been working hard at getting the ROM caught up with LP and getting the website up and running. It will be a great day!
[Nexus 6  Original Android Development] knightjs1:
If anyone read what I posted, I wasn't asking for an eta, or anything specific as to if it was working or what was needed for it to work. Just simply asked IF Slim would be implementing it. No harm no foul. I searched here and the builder's collective with no luck. Slim devs are usually a great group of guys and their threads have very little negativity. I don't run Slim for the features alone. I like the build quality as well as the way their threads are ran. Roms aren't dropped half-assed like some others. That's why I haven't flashed any of the first custom roms out the door with WiFi calling in them. Most have had some problems to sort out. Again, that's why I only ASKED if it would be implemented here. Thanks.
[Nexus 6  Original Android Development] DroidIt!:
Lol. Easy. You only asked the once before that I see and that was only a day ago. All yank was saying was have a little patience and it may get picked up. I'm not sure what needs to be implemented for it to work and probably neither does yank as he (mainly) is the one who puts out builds for this device and he doesn't live in the US, isn't on t-mob and doesn't have the option of WiFi calling. So he would basically need to research to find the commits somehow, pick them, integrate them into the ROM correctly so they work for everybody...all without being to test if it works or not and then never getting to use it for himself...sooo, maybe saying please would be good. ;)
[Nexus 6  Original Android Development] Yank555:
[MENTION=6796797]knightjs1[/MENTION] :

Nah ... you got me wrong here, I wasn't complaing about any post by anyone, I was just self-complaining against myself for not having more time for this, I just hate it when something's not working, that's all :D

So no harm anywhere at all ! :angel:

Well no harm other than for now looks like wifi calling does not work, sadly :(

If I can manage to find sth to make it work, I certainly will be glad to add it, only thing is, I won't be able to test this at all on my end, though, so I will have to rely on folks here to do the testing.

VoLTE was the same, that (so it seems to me at least) would be working now ? A confirmation (with potentially requirements like which radio, kernel...) would be nice ;)

JP.
[Nexus 6  Original Android Development] DroidIt!:
:) Honestly I don't think about looking at my data when I'm on a call to know if it works or not. Just not something I think about. I'll take a look my next phone call and give ya relevant Info's. I'm going to skip town for about a week this upcoming week, but before I go I'll see if I can help find commits for WiFi calling for t-mob, I actually have some ideas. ;)
[Nexus 6  Original Android Development] rignfool:
You might try looking at [MENTION=3357040]Imoseyon[/MENTION] 's git... He just figured out what was necessary to make it work... So it should be pretty recent in commit history
[Nexus 6  Original Android Development] DroidIt!:
Ya, I was thinking AOSiP. They got it recently too. :)
[Nexus 6  Original Android Development] Yank555:
I already PMed imoseyon ... waiting for his reply ;)

Though the question is, is kernel / ramfs enough ?

In his kernel thread, those reporting it working are running rooted stock tmo builds ... unless I'm mistaken.

I do think this needs ROM-side support as well.

Once r5 will be merged, maybe this could come to more ROMs (even devices).

JP.

---------- Post added at 09:24 PM ---------- Previous post was at 09:10 PM ----------

ROM Update

Tiny update again, includes :

- Global SlimHeadsup 3-way switch (Yank555.lu, on user request)

- Reverted the 4 suspicious bluetooth commits (for now, will dig deeper as I find time)

The bluetooth commits are in Slim base and reverting them fixes a hotreboot after listening to music for a longer period via BT connection.

As usual, ROM download links can be found in my OP in the Builders Collective, post 14.

JP.

PS: build is uploading on both servers.
[Nexus 6  Original Android Development] Andromendous:
[MENTION=2033478]Yank555[/MENTION], so are you the official maintainer for shamu? Just wondering
[Nexus 6  Original Android Development] Yank555:
Not really, just pushing builds for it, and since my shamu is my daily, I focus probably a tad more on it compared to the 3 other Nexuses I build for.

I've been given access to the OP to keep the thread updated.

Consider me rather your interim jenkins server :D

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] Andromendous:
Ok i see, i actually just built slim for myself with uberTC, i figured i could watch this thread to know when to sync up is why i asked. Question, ive been havin the aosp browser f/c on me every minute, even firefox, i wonder if it could be the kernel im running.
[Nexus 6  Original Android Development] Yank555:
As a rule of thumb, I generally sync once every 2-3 weeks, or more often if much is getting merged.

Having browsers FC could be the kernel, since browsers do run lower level stuff compared to simple Java apps.

You can quicktest my kernel to rule it out, just nandroid and flash it to check.

JP.
[Nexus 6  Original Android Development] Andromendous:
Oh im running a custom kernel, maybe i shoulda just kept it slim[emoji16] i appreciate your help tho

That might be a good test though thanks
[Nexus 6  Original Android Development] x111:
Damn it, BT connection again with interruptions.

Pls, turn it back.

on "Slim-shamu-5.1.1.alpha.0.4-UNOFFICIAL-20150629-2259", BT works as it should be.
[Nexus 6  Original Android Development] Yank555:
Aha ! Now this is eventually a feedback on BT ;)

Ok, I wanted to properly look into this issue (the 4 reverted commits, hh reboot), so for now use the previous ROM ersion, not much changed anyway in this update, we'll try to get this out of the way for the next build.

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] Biaviian:
What could I be doing wrong? I have not been able to get mobile data on any 5.1.0 builds. I just flashed the latest build (07/02) and I have the updated bootloader and radio. I have tried the APN I usually use plus everything loaded by default. I am on AT&T.
[Nexus 6  Original Android Development] JaylanPHNX:
Have you turned mobile data on? Many ROMs are starting to turn it off by default so those with very limited plans don't get a lot of usage right away.

From my SlimTab Pro 8.4
[Nexus 6  Original Android Development] tomzefi:
I flashed 7/2 5.1 also and no data. Tried everything even the sprint fix and no go. Just figured it will be fixed on the next build and I saw no one reported it also till now. Flashed different radios too. I wanted to run this update so bad too.
[Nexus 6  Original Android Development] Yank555:
Which was the last that worked for you ?

I've read that you should delete all unneeded APN that are auto-generated for AT&T, maybe same for sprint.

Do voice calls work ?

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.

---------- Post added at 09:29 AM ---------- Previous post was at 09:00 AM ----------

ROM Update

Tiny update again, includes :

- Global SlimHeadsup 3-way switch - disable per app setting in disabled/forced mode (Yank555.lu)

- Re-added the 4 suspicious bluetooth commits (caused BT audio issues on shamu, as said will dig deeper as I find time)

The bluetooth commits are back in as is, so might be a drawback for Hammerhead but should make BT work again on shamu ... [MENTION=1873462]x111[/MENTION] please confirm either way if BT works or still does not work, please.

3-way switch is brought up to the level that has now been merged.

As usual, ROM download links can be found in my OP in the Builders Collective, post 14.

JP.

PS: build is uploading on both servers.
[Nexus 6  Original Android Development] ho0o0o11111:
I also have mobile data connection problem (build 6/26)

No data is connected even if I try to enable it several times.

Either reboot or switch between air mode and back solve the problem.

It happened 2-3 times recently.

I am not sure whether this is related to rom or not, but I didn't face this problem in build 6/15.

I am going to flash the latest build 7/3 and will report back if this happens again.

Other than this issue, I enjoy this rom and yank555's build very much.

Very smooth and snappy. Great work. :)
[Nexus 6  Original Android Development] Biaviian:
The last version that worked was the last build fro 5.0.1. I'm going to flash again now to try it again. Maybe mobile data wasn't turned on. Otherwise I'll mess with APNs again.
[Nexus 6  Original Android Development] Yank555:
OK, so everything is back in "Slim-shamu-5.1.1.alpha.0.4-UNOFFICIAL-20150703-2112.zip", so that should work fine for you again. Can you please report back if that is indeed the case ?

I've also made a testbuild for you, it can be downloaded here, it has only part of the commits reverted, can you please also test this one and let me know if it's working fine or not for you, that will help me pinpoint the issue.

Thx, JP.
[Nexus 6  Original Android Development] Biaviian:
So mobile data was not enabled. Now I have mobile data but not LTE. I'm stuck on H, H+ if I'm lucky. I should have full LTE coverage where I am sitting. I have deleted all APNs and added AT&T's back.
[Nexus 6  Original Android Development] Yank555:
I suppose you set preferred network type to LTE ?

LTE hasn't ever failed me on shamu...

Can you post screenshots of the AT&T settings that work for you ? I think these should get updated in Slim's APN list.

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.
[Nexus 6  Original Android Development] Biaviian:
I got it. I re-flashed, removed all APN settings, ensured that mobile data was turned on, and set LTE to preferred. I then added the correct AT&T APN and it didn't work. Then I let it sit for about 5 minutes, nothing. Then I restarted and let it sit for 5 minutes, still nothing. I then repeated and LTE came through!
[Nexus 6  Original Android Development] Yank555:
Can you post the APN details (screenshots) ?

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.1.1 on Yank555.lu v1.1 kernel.