"Unbreak" Wacom Intuos CTL-480 on Linux Mint 17.3

With the 17.3 update of Linux Mint, the GUI that allow to set parameters for the Wacom CTL-480 broke (it doesn't recognize it anymore), but the CLI "xsetwacom" still works fine.
In my previous article i already had pointed that the GUI wasn't perfect, now it's worse ...
The only thing i need (for now) is to switch between Absolute and Relative modes for the stylus. So this will be the only thing i'll cover here (for now).
Let's workaround with a shell script that auto-switches between modes at each launch.

Xsetwacom commands
How to... by hand?

To display wacom devices attached there is the following piece of code:

xsetwacom --list devices

On my side, this outputs the following:

Wacom Intuos S Pen stylus        id: 14 type: STYLUS    
Wacom Intuos S Pen eraser        id: 15 type: ERASER    
Wacom Intuos S Pad pad           id: 16 type: PAD

To get the mode for the stylus:

xsetwacom get "Wacom Intuos S Pen stylus" mode

To set Relative mode for the stylus:

xsetwacom set "Wacom Intuos S Pen stylus" mode relative

The script
The power of sed

As the output of "xsetwacom --list devices" is longer than the string needed for the set command, let's trim it with sed: (the following command allows variation in the device name, as when the tablet is connected with the wireless module it has "(WL)" in its name.
Note that the gap after the used name is variable (it is made of zero or more space(s) and one indentation, the sed command takes care of that)

Then the script will check for the mode and switch between both!

To launch the script, refer to my old post about m505 remapping script.
The potential updates to this script will be available on my github.

Quickie#4 CM12.1 vs Exodus ROM: CPU/GPU

After Pure SQLite databases transactions performances, it is time to have a look at CPU/GPU pure performances (meaning benchmarking, not real-life ...)

CPU
RgbenchMM

both ROMs were tested on RgbenchMM (4 threads):

On this Benchmark, CM12.1 is slightly ahead in performances (this has no real-life impact though)

GPU: 2D
fps2D

For 2D graphics, i use fps2D, and old app that is quite great for the purpose (an keeping it helps looking back in the ages and see progression.

No, there is absolutely NO single difference regarding 2D performances. a 0.1 fps difference with a standard deviation of 10fps is not significant at all!

GPU: 3D
GPUbench

Looking at average fps performance on this benchmark shows less than 1 fps difference between the two ROMs. lowest and highest are much more variable (look at stdev!) and thus cannot be compared.

What about the score?

Looks like CM12.1 gets some higher scores here? Right, but mainly because the Benchmark didn't recognized the same screen resolution (although both are set to 320dpi [default]) ==> normalized scores are similar. This might need further investigations.

Conclusion
regarding CPU/GPU

• Contrary to the huge performance increase in SQLite (up to 900%!!) CPU/GPU performances are not better (even a little behind? not sure we can say that) on Exodus compared to CM12.1
• So after hours of benchmarking, i couldn't show Exodus superiority here. So for people wanting a pure CM experience there is no point switching to Exodus of Falcons (XT1032 at least.) to burst CPU/GPU Benchmarks.
• Nevertheless, those ROMs are pretty similar but Exodus features lots of things CM12.1 doesn't which is not something to throw out!
• Later we will try to see if various other points of comparison can (or not?) differenciate Exodus from CM12.1.
  But are we really searching overkill performances in Exodus on Falcon? I personally don't. CM12.1 is a great stable base that gave me all i wanted for a while (Features and performance wise).
  What i searched for in Exodus is not extra performances, but extra features (Pie, navigation bar customs, bottom right clear-recent, ...)

Quickie#3 CM12.1 vs Exodus ROM : SQLite performance

Having two devices with similar hardware helps a lot for "real-time" comparisons of different ROM at a given time. Here we are comparing CM12.1 (20151012 nightly) with Exodus ROM (based on 12.1 ... 20151012) regarding SQLite databases performances, this is not like a full ROM versus, simply a comparison on a very specific point.

The devices
Similar Hardware ? yes, and no...

The two devices are both XT1032, with pretty similar hardware, but with some differences regarding memory :

*	Device 1	Device 2
ROM	CM12.1	Exodus
eMMC	8GB Sandisk	16GB Toshiba
/data file system	F2FS	F2FS
DRAM	1024MB Samsung S4	1024MB Hynix S4

(does this adds a significant bias? hmmm maybe, but it won't explain the gigantic differences seen later)

Benchmarking
AndroBench 4.1

Here i am testing pure SQLite performances with AndroBench 4.1 on both devices using BFQ scheduler (default CM and Exodus I/O scheduler since quite a while)-results in Transactions Per Seconds (TPS)-

	Exodus-BFQ		CM12-BFQ
	average	stdev	average	stdev
SQLite Insert	1241,40	21,19	116,22	4,48
SQLite Update	632,82	12,41	107,78	2,82
SQLite Delete	952,57	16,57	118,21	5,81

Looks like there's quite a big difference... isn't it?
In day to day usage i don't feel much gap between those two ROMs, but this specific benchmark shows that Exodus had more in-depth optimizations regarding SQLite database operations

Discussing bias:

• Memory brand is different, your results are messed up: No, in fact other devices (aka Moto E 1st gen [XT1022, eMMC: Hynix, DRAM 1024MB Hynix S4, Snapdragon200] or MotoG 2d gen) show similar results on CM12.1 (or even lower for the MotoE). So even if the brand may have a little impact on performance, it won't explain the 10^1 between results.
• As Processing unit has a fairly big impact on I/O performances, both devices are featuring a Snapdragon 400 @1.2GHz, Interactive governor, MP decision enabled.
• Is choosing BFQ as scheduler impacts results? and why choosing it? BFQ is the default scheduler for both CM12.1 and Exodus, for this simple reason there is no point testing another in first-line. Plus it could be interesting to see if the optimizations have been directly applied to this specific scheduler or if they are more system-wide. On previous tests i couldn't show any difference in performance between BFQ and Fiops regarding SQLite Update or Delete operations.
• SQLite databases are not reflecting real-life performance though, so this only shows a very little part of everything -but should make benchmarks addicts happy ;-) -

CM12.1 : A few Drawbacks

I'm using CyanogenMod ROMs since the very beginning (started with a fork of CM6 called MiniCM6 by XDA Recognized Developer nobodyAtall).

Every CM version since then had more and more features, less and less bugs: the Sony-Ericsson X10mini (e10i, aka Robyn) started with the 'well-known' "SDcard safe to remove" reboot bug that crashed the device twice a day in the early miniCM6 ages...,
CM12.1 on Falcon (Motorola MotoG, XT1032) is far from this, a lot more mature, but still lacks a few things

CM12.1
Some lacking Features and some issues

Here is a list of a few things that bothers me in CM12.1. Don't take it wrong, CM12.1 is nice and works pretty well, the following list is only a few "cosmetic" issues, user-experience related.

• Expanded Desktop
  • Sometimes the nav bar doesn't show up when swiping up. (It needs to swipe down to display notifications, and then, nav bar shows up)
  • On some specific apps the nav bar is "ghost" meaning that once displayed (after swiping up) touching return buttons behaves as if the user had touched the content behind [like an ad........])
• "Per App" Expanded desktop
  • Enabled for all is nice,
  • Per app settings is nice, -when "Enabled for all" is un-checked-
  • BUT why can't we make per app customisation, when "Enabled for All" is checked? that would help when the user wants the expanded desktop to be enabled for NEARLY all apps, but keeping a few apps with both nav and status bar.
• 'The random Black Screen' with AmbientDisplay (with wave to wake, an pocket mode enabled)
  • In some rare cases, getting a notification wakes the device, but screen goes black (the only way to "fix" is force rebooting the device). Still no way to reproduce found yet,
• LiveDisplay : Automatic settings
  • Automatic settings only work when location is enabled. A great addition would be to set time of start and time of end of 'night-mode' as whe can do with F.lux or RedShift for users that don't keep location enabled all-the-time.
• LMK, is that really an issue?

Feel free to comment below, and i will update this article with your own feelings about the lacking features and the issues that bother you in CM12.1 (don't forget to tell your device if the issue is specific to a branch

For those complaining about Battery Life, don't forget to read this article ;-)

Tip of the day: restoring WiFi settings after a factory reset

For some reason you may want to perform a clean install but don't want to waste all your spare time setting your complicated WiFi setup ?
Sadly you forgot to backup the WiFi settings (and google failed to re-sync them) but performed a Nandroid backup? 

 all the following steps can be performed directly on device, tested on Falcon running CM12 

story backgroung: after a buggy CM12 update and a failed rollback, my wifi settings were gone and google had synced the "blank" wpa_supplicant.conf file, i had no choice but trying to find a way to recover all the passphrases.

If you used TWRP, then things will be quite easy: 

• Take your backup, 
• Seek for data.f2fs.win 
• Copy it to a dedicated folder and 
• Rename it to data.tar.gz 

Assuming the backup is on your USB otg: 

1. Open terminal and type: cd /storage/usbdisk/TWRP/backup/ 
2. Make sure the file is there: ls 
3. Untar: tar -xvzf data.tar.gz 
4. After the unarchiving is completed you can search for ./misc/wifi/wpa_supplicant.conf 
5. Rename the existant one (/data/misc/wifi/wpa_supplicant.conf to wpa_supplicant.conf.bak)
6. Paste the new one there and 
7. Give proper permissions/owner/group (-rw-rw----, owner 1000-system, group 1010-wifi). 

 Your WiFi settings are back and you can now focus on more interesting things.

If you want to discuss about this subject, meet us at xdadevelopers.com

Battery Life: the Unexpected Extinction (OR how we lost it)

Since the very beginning of Android everyone has been talking about Battery Life... and how bad it is; but why that much hate?

Let's investigate:

For the following, i had only based the research on the devices i owned/used:

• Sony Ericsson Z530i
• Xperia X10mini (E10i)
• Motorola Moto G (XT1032/XT1039)
• Motorola Moto E (XT1022)

Impacting points But... What are the culprits??

Here are some, but i'm sure there are many more things that impact battery life.

Hardware:

• Device global power and Screen size/technology vs battery size
• Antenna quality and network coverage

Software:

• Firmware: Kernel, ROM... (implementation, and optimization regarding hardware)
• background services (viber, facebook, google services [location seeking, google fit, google wear, ...], ...)

User:

• User habits
• ...

There are lots of variables in the equation so we cannot "benchmark" them as we do for performances; the following won't give answers, but more questions that anybody should ask themselves when talking about battery life.
A good study would need known and fixed variables to investigate on one specific variable, with negative and positive controls, triplicates, and statistics to show significant differences. But we have none.

Hardware Power, Screen Size/tech, Battery Size...

We have 4 (5) devices from 3 generations:

• The "old phone"
• The early smartphone (The e10i was shipped with android 1.6 donut!) and
• The current gen entry/middle class smartphones (XT1022-XT1032-XT1039)

The oldest features a 128*160px screen for a 900mAh battery and could handle more than a week and a half without the need of a charge (up to 2 weeks with moderate usage)
The X10mini features a 240*320px screen for a 950mAh battery and could only stay on for about 24hrs-48hrs
The MotoG: 720*1280px for 2070mAh (24-48hrs)

The MotoE: 540*960px for 1980mAh (48-72hrs, and up to a week with fair usage)

Here is chart about battery capacity (mAh) and screen surface (px) coefficients between my first phone (Z530i) and the newer devices:

device	length	width	surface (px)	battery (mAh)
Z530i	160	128	20480	900	surface increase	battery increase
E10i	320	240	76800	950	3,75	1,06
XT1022	960	540	518400	1980	25,31	2,20
XT1032	1280	720	921600	2070	45,00	2,30

Z530i --> XT1032 : 2.3x battery capacity increase, but a 45x wider screen!!
Luckily, battery life had not been decrease by 20! (only by 7~14)

Screen technology also plays a role in power consumption: 
A standard TFT/IPS screen uses a whole backlight that is either ON or OFF (+ brightness levels) meaning similar power used regardless the displayed content.
On the opposite, AMOLED based screens don't have any: these screens features LEDs for each pixel that are completely OFF when a screen part is black meaning NO power used at all!
The previously named devices are all using TFT/IPS based screen though.

CPU and GPU are not much relevant (regarding clock since MHz/W has been increased a lot making newer devices a lot more efficient); this point would need a whole in depth article, so we won't study this much now.

Antenna quality has a lot to do with battery life, the better the antenna, the better the life: the device would need less power to get same signal, saving some more juice.

Network Coverage isn't directly linked to hardware (since it is not relateed to the device itself, --in fact yes if we consider the bands handled by the device and the ones provided by the MNO--)

Software Hardware isn't the only one

Implementation and optimization:
A well optimized software for a specific hardware can move mountains, as easily as a bad one will sink in the deep see...
That's easy to show for benchmarks (see my comparison between stock and CM11 on MotoG and impact on MFLOPS), but hard for battery life (too many other un-fixable variables).

All we can say here is that a process that needs more CPU cycles to perform an action will keep it awake longer, thus resulting in more power consumption and a shorter battery life.

Background services:
Google IS Evil, yes, their services are running in the background at any time and everywhere. Most of them won't be used by the end user, but f***k it, they are alive!
"- i'm looking at you location seeking, google fit, google wear, google search,..."

Facebook (app and messenger), Viber, ... All these apps use some services to keep refreshing for potential notification, calls, pokes...

What can we do?
Seek for wakelocks using Wakelock Detector,
Hibernate apps you don't use with Greenify,
Ask in the Forums for some advice

User habits 99% of bugs are between screen and chair

Who said the device was all culpable?

Look at yourself, what are you doing with your device right now? maybe reading this article from you phone/phablet? Playing all day long? Answering emails? Checking twitter/facebook/whatever? Browsing 9gag?

Didn't you changed your usage of the so called 'smart'-phone? are you doing the same as you were on your old 'not-that-dumb'-phone?

Wacom Intuos CTL-480 and Linux Mint 17.1

I recently purchased a Wacom Intuos Pen CTL-480, that i'm now using exclusively with Linux (mostly Linux Mint 17.1 x64 Cinnamon and Xfce edition)

This won't be an unboxing as there are many on the Internet. One observation though, i was pretty surprised that the wireless kit is 100% embedded in the tablet once plugged in it :

After the cover is placed back: everything is totally invisible. Well done Wacom! (when i purchased it i wasn't sure it would be that much stealth and feared it would make an hideous extension on the back)

Let's talk software: 

On Linux Mint 17.1 Cinnamon ==> Plug&Play (mostly)

Only thing missing : the four buttons on the tab are mapped by default, but cannot be reset using that utility. 

Playing with xev and xinput might be necessary.

MyPaint and GIMP perfectly handle the tab.

Major issue with battery status of the wireless kit:

Here is one of my very firsts paintings (using MyPaint and its marvelous brushes):

a few screenshots of steps to draw a baby dragon :

MotoG : Pure CPU Benchmarks, the limits

To point out pure CPU Benchmark flaws, we'll observe how does a moto G (Falcon or Peregrine, this has no relevance) behaves with Linpack Benchmark when running on Stock 4.4.4 Motorola ROM or CM11-20141124-nightly (4.4.4).

We have seen previously that Linpack didn't use all cores and was limited to 3 threads in multi-thread benchmarking (when comparing s200 and s400 SoC).

Now, we will compare MFLOPS performance between two ROMs that has similar user experience (smoothness mostly)

Stock 4.4.4 Motorola ROM vs CM11

both @1190MHz, Interactive governor.

Stock Motorola features a nearly doubled score for both Single and Multi-Thread, but does that mean it is really better optimized?

• In a way, yes, CM11 is made to be compatible with most devices, so we encounter similar problem seen with Windows against iOS : 
• An OS that fits all against a fully optimized one made for a few specific hardware. Motorola obviously optimized their software to get the best of this great device
• If you compare with the MotoG vs MotoE test, you'll see that the MotoG running CM11 has lower results than MotoE running stock ROM ...

• On the other hand, that's not all a matter of optimization :
• CM11 features KSM, zRAM, and many things that use CPU cycles to compress memory (zRAM) or merging merge-able things (KSM) ==> this reduces CPU pure performance but increase multi-tasking ability.
• The war of versatility and customization against slickness and stability...
• Honestly i can't see difference in user-felt performances...

Actually, i don't see any issues by using CM11 as a daily driver on my XT1032 (Falcon), it is not because a Benchmark say something that it is true in "real life"...

• Don't use CM11 on Moto G if you want to show off with high CPU benchmark results ...
• Stock Motorola ROM is close enough to AOSP to be acceptable as daily driver
• Xposed helps you to get the best of stock ROM
• CM11 is great for end-user customization

The real conclusion is the following :

Don't trust Benchmarks as incontestable truth, they helps to compare devices and  ROMs, but never really tell you how good devices/ROMs are.

Moto G and Moto E : snapdragon 400 vs 200

Snapdragon 400 vs Snapdragon 200 based on msm8926/8226 vs msm8610

After we studied MFLOPS per MHz ...

It is now time to compare MotoE and MotoG:

Moto G and E features a Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz)

Note that previous benchmarks were performed with ONDEMAND governor on CyangenMod11 ROM, but stock Moto ROM uses Interactive by default (i didn't expected that...) so the following has been made with interactive for both devices (needed to re-bench MotoG >_<)

to check above results are applicable despite governor modification : 

MFLOPS per governor on MotoG (Falcon, CM11) @1190MHz

No significant difference between ONDEMAND and Interactive governors for the specified test.

Moto G (Peregrine) vs Moto E (Condor) msm8926 vs msm8610

To improve accuracy, instead of using my Falcon (XT1032) running CM11, we will compare results obtained on a Peregrine (XT1039) running Stock Motorola ROM :

Both Benchmarks have been run on Motorola Stock 4.4.4 ROM on Moto G (Peregrine) and Moto E (Condor):

There is no differences between msm8226 (Falcon) and msm8926 (Peregrine) despite LTE capability of msm8926, that's why we will use a Peregrine for the following part.

MotoG (Peregrine) vs MotoE (Condor) @1190MHz, stock 4.4.4

We have quite similar results on Single Thread application for one simple reason, the number of cores does not have any impact. Since the clock speed is the same, the results are the one expected.

On Multi-thread the difference is quite huge between the quad-core and the dual-core, though we don't see a x2 ratio by doubling the cores number.

MFLOPS divided per the amount of cores

x/4 for msm8926 and x/2 for msm8610, Single Thread as control.

We should have observed a similar result between Single and Multi/nbCore...
Is the msm8926 really shitty at multithreading? i don't think so, looks more like if linpack or the system only uses 3 Threads...

If we apply a corrective divider (3 instead of 4) the results are perfect :

MFLOPS divided per the amount of threads used

x/3 for msm8926 and x/2 for msm8610, Single Thread as control.

Moto E (Condor) and Moto G (Peregrine or Falcon) should have similar performance in single threaded applications.

Though the 4 Cores may no be used at their full potential in some apps, multi-threaded applications should be better handled by the msm8926/8226 featured by moto G.

Moto G? or Moto E? Which one for What...

For moderate usage, Moto E is quite enough compared to Moto G : 

• It is not weaker on Single Threaded applications
• It has a smaller battery but both smaller CPU and half size Screen in pixels (960*540 vs 1280*720) will give it a great battery life.

Moto G is still the best quality/price in its category (prefer the Peregrine version and not the Moto G 2014 aka Titan)

• Multi-threaded applications will obviously run better on it
• The better Screen density improves user experience on long term usage
• A far better Camera...

A complete Moto G - Moto E versus is available on versus.com (note that Moto G Peregrine does not have 16GB of internal memory ... but only 8, and an SDcard slot.)

Installing Opera 26 and Adobe Flash Player? Pepper Flash!

After the Linux Mint 17.1 upgrade, why not trying Opera 26 ? (Opera had not been updated for Linux since Opera 12 before this new release)

Getting to the Opera Web Page and downloading the x64-only .deb :

Installing the deb package : (the package will seek for dependencies)

If you want Opera to get its updates with system updates, then :

Need Adobe Flash Player ?
What about using Pepper flash instead of Adobe oldies?

sudo apt-get install pepperflashplugin-nonfree

Restarting Opera, and we're done!

Moto E and Moto G : 2 White LEDs

After my articles about the "Two LEDs" discovered on MotoE (and suspected on MotoG) i received a lot of questions about them : 

• Are there really Two LEDs there??
• Are they really White and not RGB "mis-configured"?

So i made non-destructive tests using a microscope on Moto E:

For some reason, MotoE LED hole is transparent and we can see through it (that's not the case for MotoG)

2 LEDs The proof that MotoE has 2 LEDs

Here is a picture taken at x100 of the notification LED ON (triggered through /sys/class/leds/white since the brighter one was too bright to allow me to take a pic of it lighten up with my set up)

Each "yellow" rectangle is a LED chip (you can see the two wires on the left one)

This is proof there is two LEDs, i was able to light them both using the following : 

echo 255 >/sys/class/leds/charging/brightness #to light the left and brighter one
echo 255 >/sys/class/leds/white/brightness #to light the one on the right

White LEDs The proof that Moto E has white only LEDs

On the above picture, you can see a closer view of the LED: its inner components and something interesting :

• there are 2 wires: this should correspond to +/- (proof of Single color LED)

[source : Wikipedia]

• The light emitted is white (that could be RGB set to 255:255:255) BUT, there is a Blue shift (the blue luminescence you can see around the center of the LED) which  corresponds to a Blue LED with a phosphor substract coated on it giving the White light.

[source : Wikipedia]

We now know that Moto E has 2 LEDs and that they are White only, 
I cannot prove it for motoG until complete teardown (the LED hole does not allow to see through it and observe the LEDs) but there are good chances that it also has 2 white LEDs regarding the behavior in previous tests.


Make sure you read these articles to understand how this started :

MotoG play with the LED

MotoE play with the LED