port BlueLightFilter at kernel? - Samsung Galaxy S7 Edge Questions and Answers

amazing kernel port-er or mode-er are from this section so I post the question at here. I had tried for the past 2 weeks but no luck, so my last resort is to question the genius of xda.
A brief introduction: Samsung stock BlueLightFilter is not using overlay like 3rd part apps, the benefit is it will not get blur when you increase the intensity.
I see no reason why I shouldn't share the thing I already knew to everyone, sharing is caring:
I got some clue to get it working, you have to edit the kernel. I get more specific clue you have to edit the mdnie file
https://forum.xda-developers.com/showpost.php?p=74542731&postcount=327 @BlackMesa123
Which is correct when I check https://forum.xda-developers.com/samsung-a-series/development/advanced-seven-t3509237
https://github.com/jjhitel/ASKernel by @jjhitel it is indeed the mdnie.h, mdnie_lite.c and mdnie_lite_table_A7xe.h that are modified
The code are from G920FXXU5EQAC kernel code, just lucky they spot the same screen size. Not sure how these values are generated:
static unsigned char coordinate_data_2[] = {
0xff, 0xff, 0xff, /* dummy */
0xff, 0xf6, 0xec, /* Tune_1 */
0xff, 0xf7, 0xf0, /* Tune_2 */
0xff, 0xf8, 0xf4, /* Tune_3 */
0xff, 0xf9, 0xed, /* Tune_4 */
0xff, 0xfa, 0xf1, /* Tune_5 */
0xff, 0xfb, 0xf4, /* Tune_6 */
0xff, 0xfc, 0xee, /* Tune_7 */
0xff, 0xfd, 0xf0, /* Tune_8 */
0xff, 0xfe, 0xf4, /* Tune_9 */
};
Advanced Seven rom is the example that someone port it to the rom without blf. But I have no idea what is/are the framework file(s) needed to be modified
I even tried directly take Note 5's mdnie.h, mdnie_lite.c and mdnie_lite_table_ compile and boot with no error but not working.
Then I tried match mdnie_lite_table_noble to my mdnie_lite_table_j7xe.h still boot with no error but not working.
I already added BlueLightFilter apk back but when turn on and off nothing happen.
Here is my device kernel source code
https://github.com/doulcXDA/Nougat-...kernel/drivers/video/exynos/decon_7580/panels
video\exynos\decon_7580\panels\mdnie.h
video\exynos\decon_7580\panels\mdnie_lite.c
video\exynos\decon_7580\panels\mdnie_lite_table_j7xe.h
To sum the question what I want to ask, how to get BlueLightFilter working?
Question is, do both aod and blf need to mod framework.jar to get it working?
I am targeting framework.jar or services.jar but I didn't get anything when compare both jar's smali
Can those godlike experienced master take a look at this for always on display and bluelight filter please?
I have both services.jar and framework.jar from my phone(no blf and aod) and targeting phone(with blf and aod)
services.jar
https://mega.nz/#!LUUVjbxZ!KqP5W7M23PKDt5jhkAiYXjwj1h2IwvGl-cW42u4T6nE
framework.jar
https://mega.nz/#!eU8DWaIb!HEjloERDK91VpNXvYupIdEb4X-7ii-oPKXcp9huf__o
I don't mind alternative approach actually as long as it can filter blue light out like kcal but kcal only support snapdragon not exynos.

Related

Sample of Nokia.c found in cyanogenmod-sony-kernel-msm8960 for USB driver.

Was searching for Qualcomm drivers to throw at my Lumia. Same cpu and looks like it was written for PC Suite Mode. Actually there's Nokia stuff all over in the folder I downloaded. Found here http://searchcode.com/codesearch/view/42236209.
Code:
/* nokia.c -- Nokia Composite Gadget Driver
*
* Copyright (C) 2008-2010 Nokia Corporation
* Contact: Felipe Balbi <[email protected]>
*
* This gadget driver borrows from serial.c which is:
*
* Copyright (C) 2003 Al Borchers ([email protected])
* Copyright (C) 2008 by David Brownell
* Copyright (C) 2008 by Nokia Corporation
*
* This software is distributed under the terms of the GNU General
* Public License ("GPL") as published by the Free Software Foundation,
* version 2 of that License.
*/
#include <linux/kernel.h>
#include <linux/utsname.h>
#include <linux/device.h>
#include "u_serial.h"
#include "u_ether.h"
#include "u_phonet.h"
#include "gadget_chips.h"
/* Defines */
#define NOKIA_VERSION_NUM 0x0211
#define NOKIA_LONG_NAME "N900 (PC-Suite Mode)"
/*-------------------------------------------------------------------------*/
/*
* Kbuild is not very cooperative with respect to linking separately
* compiled library objects into one module. So for now we won't use
* separate compilation ... ensuring init/exit sections work to shrink
* the runtime footprint, and giving us at least some parts of what
* a "gcc --combine ... part1.c part2.c part3.c ... " build would.
*/
#include "composite.c"
#include "usbstring.c"
#include "config.c"
#include "epautoconf.c"
#include "u_serial.c"
#include "f_acm.c"
#include "f_ecm.c"
#include "f_obex.c"
#include "f_serial.c"
#include "f_phonet.c"
#include "u_ether.c"
/*-------------------------------------------------------------------------*/
#define NOKIA_VENDOR_ID 0x0421 /* Nokia */
#define NOKIA_PRODUCT_ID 0x01c8 /* Nokia Gadget */
/* string IDs are assigned dynamically */
#define STRING_MANUFACTURER_IDX 0
#define STRING_PRODUCT_IDX 1
#define STRING_DESCRIPTION_IDX 2
static char manufacturer_nokia[] = "Nokia";
static const char product_nokia[] = NOKIA_LONG_NAME;
static const char description_nokia[] = "PC-Suite Configuration";
static struct usb_string strings_dev[] = {
[STRING_MANUFACTURER_IDX].s = manufacturer_nokia,
[STRING_PRODUCT_IDX].s = NOKIA_LONG_NAME,
[STRING_DESCRIPTION_IDX].s = description_nokia,
{ } /* end of list */
};
static struct usb_gadget_strings stringtab_dev = {
.language = 0x0409, /* en-us */
.strings = strings_dev,
};
static struct usb_gadget_strings *dev_strings[] = {
&stringtab_dev,
NULL,
};
static struct usb_device_descriptor device_desc = {
.bLength = USB_DT_DEVICE_SIZE,
.bDescriptorType = USB_DT_DEVICE,
.bcdUSB = __constant_cpu_to_le16(0x0200),
.bDeviceClass = USB_CLASS_COMM,
.idVendor = __constant_cpu_to_le16(NOKIA_VENDOR_ID),
.idProduct = __constant_cpu_to_le16(NOKIA_PRODUCT_ID),
/* .iManufacturer = DYNAMIC */
/* .iProduct = DYNAMIC */
.bNumConfigurations = 1,
};
/*-------------------------------------------------------------------------*/
/* Module */
MODULE_DESCRIPTION("Nokia composite gadget driver for N900");
MODULE_AUTHOR("Felipe Balbi");
MODULE_LICENSE("GPL");
Wow. Looks interesting. Will look through it tommorow.
Don't really know whether it's useful, as I'm not a developer, but this smells like possibility of ANDROID (lol) for Lumia.
Well, N900...
"Nokia composite gadget driver for N900"
ice8lue said:
Well, N900...
"Nokia composite gadget driver for N900"
Click to expand...
Click to collapse
Yes N900 driver in the kernel for a Sony Experia running Android on the same chip used in most Lumias if I am not mistaken. In the right hands maybe useful, maybe not, but thought it interesting....
Hmmm maybe a little closer to a way to flashing unsigned firmware updates?

[GUIDE] Color correction. Loadable mDNIe color profiles.

I hope I've brought something useful here.
I figured out how to load mDNIe color profiles from sdcard.
So this I found out so far:
1. you have to be rooted;
2. profiles MUST be placed in /sdcard/mdnie folder;
3. profile is a text file and can be edited with any text editor;
4. file name is irrelevant ;
5. you have to edit two titles inside profile file to correspond to profile, you're going to override, eg. you're using AMOLED cinema mode. It's internal name is DYNAMIC_UI, so titles inside profile should be DYNAMIC_UI_1 for longer array and DYNAMIC_UI_2 for shorter one.
The whole list of model with corresponding internal names:
AMOLED cinema mode - DYNAMIC_UI;
AMOLED photo - STANDARD_UI;
Basic - NATURAL_UI;
6. first lines (bytes) of arrays are special marks (0xEC and 0xEB) and should not be touched;
7. to enable profile you have to write into /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning:
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
UPDATE:
Written a small app for PC to tune colors through ADB. Useful for displaying some fullscreen test picture on device and drag sliders on PC to see effect (if any).
Profile structure description is in 2nd post.
That's it by now. There are comments from kernel source, but not too much descriptive (attached here).
I'd extracted and formated properly some major profiles. Attaching them here. Now we need to play allot with them to find out what each byte is doing exactly.
All profiles attached here have matching line numbers. I suggest to keep this pattern, so it will allow us to refer particular byte by line number while discussing here.
Profile bytes with description:
Description will be updated as figured out.
Code:
1 : BYPASS_2
2 : {
3 : 0xEB,
4 : 0x01, /* mdnie_en */
5 : 0x00, /* data_width mask 00 0000 */
6 : 0x00, /* ascr_roi 1 ascr 00 1 0 */ (only odd values 1-155, affects lines 132-155)
7 : 0x02, /* algo_roi 1 algo lce_roi 1 lce 00 1 0 00 1 0 */
8 : 0x00, /* roi_ctrl 00 */
9 : 0x00, /* roi0_x_start 12 */
10 : 0x00,
11 : 0x00, /* roi0_x_end */
12 : 0x00,
13 : 0x00, /* roi0_y_start */
14 : 0x00,
15 : 0x00, /* roi0_y_end */
16 : 0x00,
17 : 0x00, /* roi1_x_strat */
18 : 0x00,
19 : 0x00, /* roi1_x_end */
20 : 0x00,
21 : 0x00, /* roi1_y_start */
22 : 0x00,
23 : 0x00, /* roi1_y_end */
24 : 0x00,
25 : };
26 : BYPASS_1
27 : {
28 : 0xEC,
29 : 0x18, /* lce_on 0 lce_gain 0 0 00 0000 */
30 : 0x24, /* lce_color_gain 00 0000 */
31 : 0x10, /* lce_scene_change_on scene_trans 0 0000 */
32 : 0x14, /* lce_min_diff */
33 : 0xb3, /* lce_illum_gain */
34 : 0x01, /* lce_ref_offset 9 */
35 : 0x0e,
36 : 0x01, /* lce_ref_gain 9 */
37 : 0x00,
38 : 0x66, /* lce_block_size h v 0000 0000 */
39 : 0xfa, /* lce_bright_th */
40 : 0x2d, /* lce_bin_size_ratio */
41 : 0x03, /* lce_dark_th 000 */
42 : 0x96, /* lce_min_ref_offset */
43 : 0x00, /* nr sharp cs gamma 0000 */ (unsharpen mask radius (0-15))
44 : 0xff, /* nr_mask_th */ (unsharpen mask threshold)
45 : 0x00, /* sharpen_weight 10 */ (unsharpen mask strength (0-199))
46 : 0x00,
47 : 0x07, /* sharpen_maxplus 11 */
48 : 0xff,
49 : 0x07, /* sharpen_maxminus 11 */
50 : 0xff,
51 : 0x01, /* cs_gain 10 */
52 : 0x00,
53 : 0x00, /* curve_1_b */
54 : 0x20, /* curve_1_a */
55 : 0x00, /* curve_2_b */
56 : 0x20, /* curve_2_a */
57 : 0x00, /* curve_3_b */
58 : 0x20, /* curve_3_a */
59 : 0x00, /* curve_4_b */
60 : 0x20, /* curve_4_a */
61 : 0x00, /* curve_5_b */
62 : 0x20, /* curve_5_a */
63 : 0x00, /* curve_6_b */
64 : 0x20, /* curve_6_a */
65 : 0x00, /* curve_7_b */
66 : 0x20, /* curve_7_a */
67 : 0x00, /* curve_8_b */
68 : 0x20, /* curve_8_a */
69 : 0x00, /* curve_9_b */
70 : 0x20, /* curve_9_a */
71 : 0x00, /* curve10_b */
72 : 0x20, /* curve10_a */
73 : 0x00, /* curve11_b */
74 : 0x20, /* curve11_a */
75 : 0x00, /* curve12_b */
76 : 0x20, /* curve12_a */
77 : 0x00, /* curve13_b */
78 : 0x20, /* curve13_a */
79 : 0x00, /* curve14_b */
80 : 0x20, /* curve14_a */
81 : 0x00, /* curve15_b */
82 : 0x20, /* curve15_a */
83 : 0x00, /* curve16_b */
84 : 0x20, /* curve16_a */
85 : 0x00, /* curve17_b */
86 : 0x20, /* curve17_a */
87 : 0x00, /* curve18_b */
88 : 0x20, /* curve18_a */
89 : 0x00, /* curve19_b */
90 : 0x20, /* curve19_a */
91 : 0x00, /* curve20_b */
92 : 0x20, /* curve20_a */
93 : 0x00, /* curve21_b */
94 : 0x20, /* curve21_a */
95 : 0x00, /* curve22_b */
96 : 0x20, /* curve22_a */
97 : 0x00, /* curve23_b */
98 : 0x20, /* curve23_a */
99 : 0x00, /* curve24_b */
100 : 0xff, /* curve24_a */
101 : 0x20, /* ascr_skin_on strength 0 00000 */
102 : 0x67, /* ascr_skin_cb */
103 : 0xa9, /* ascr_skin_cr */
104 : 0x0c, /* ascr_dist_up */
105 : 0x0c, /* ascr_dist_down */
106 : 0x0c, /* ascr_dist_right */
107 : 0x0c, /* ascr_dist_left */
108 : 0x00, /* ascr_div_up 20 */
109 : 0xaa,
110 : 0xab,
111 : 0x00, /* ascr_div_down */
112 : 0xaa,
113 : 0xab,
114 : 0x00, /* ascr_div_right */
115 : 0xaa,
116 : 0xab,
117 : 0x00, /* ascr_div_left */
118 : 0xaa,
119 : 0xab,
120 : 0xff, /* ascr_skin_Rr */
121 : 0x00, /* ascr_skin_Rg */
122 : 0x00, /* ascr_skin_Rb */
123 : 0xff, /* ascr_skin_Yr */
124 : 0xff, /* ascr_skin_Yg */
125 : 0x00, /* ascr_skin_Yb */
126 : 0xff, /* ascr_skin_Mr */
127 : 0x00, /* ascr_skin_Mg */
128 : 0xff, /* ascr_skin_Mb */
129 : 0xff, /* ascr_skin_Wr */
130 : 0xff, /* ascr_skin_Wg */
131 : 0xff, /* ascr_skin_Wb */
132 : 0x00, /* ascr_Cr */ red in cyan
133 : 0xff, /* ascr_Rr */ red in red
134 : 0xff, /* ascr_Cg */ green in cyan
135 : 0x00, /* ascr_Rg */ green in red
136 : 0xff, /* ascr_Cb */ blue in cyan
137 : 0x00, /* ascr_Rb */ blue in red
138 : 0xff, /* ascr_Mr */ red in magenta
139 : 0x00, /* ascr_Gr */ red in green
140 : 0x00, /* ascr_Mg */ green in magenta
141 : 0xff, /* ascr_Gg */ green in green
142 : 0xff, /* ascr_Mb */ blue in magenta
143 : 0x00, /* ascr_Gb */ blue in green
144 : 0xff, /* ascr_Yr */ red in yellow
145 : 0x00, /* ascr_Br */ red in blue
146 : 0xff, /* ascr_Yg */ green in yellow
147 : 0x00, /* ascr_Bg */ green in blue
148 : 0x00, /* ascr_Yb */ blue in yellow
149 : 0xff, /* ascr_Bb */ blue in blue
150 : 0xff, /* ascr_Wr */ red in white
151 : 0x00, /* ascr_Kr */ red in black
152 : 0xff, /* ascr_Wg */ green in white
153 : 0x00, /* ascr_Kg */ green in black
154 : 0xff, /* ascr_Wb */ blue in white
155 : 0x00, /* ascr_Kb */ blue in black
156 : };
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
UpInTheAir said:
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
heyjoe66 said:
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
Click to expand...
Click to collapse
Yes, I understand that. I wish to add the control into Synapse, no need for scripts or other apps, that's all
I do have control for similar with my Note 3 kernel. I just might try implement some of it, stock or not.
Sent from my SM-N9005 using XDA Premium 4 mobile app
Ok, let me be the first who admits it, I have no glue how to calibrate the screen with your tools. Could you post a step by step guide or even Youtube video? That would be awesome.
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Orphee said:
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Click to expand...
Click to collapse
Hi,
(from app description)
Look for other ColorTRUE Aware Apps
Unlike your laptop or desktop operating system, Android mobile apps do not have system wide color management capabilities. Therefore, each app must apply color profiles individually. For this reason, X-Rite has created the ColorTRUE Aware Partner Program. We are currently collaborating with other app developers to allow them to seamlessly access your ColorTRUE profile so any app can display colors accurately and consistently. ColorTRUE Aware apps will be color managed once you create a profile with ColorTRUE. Just look for the ColorTRUE Aware logo for compatibility.
Click to expand...
Click to collapse
Looks like it doesn't use mdnie.
heyjoe66 said:
Hi,
(from app description)
Looks like it doesn't use mdnie.
Click to expand...
Click to collapse
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Orphee said:
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Click to expand...
Click to collapse
Not sure if I know what to do with this. I can see some values in the Profile Explorer you provided, but I have no idea, what threy mean.
I tried to read a bit about ICC, like here and here, but seriously, that's too much new info for me right now.
The most terrible thing about color here that bothers me is that color reproduction is heavily depend on screen brightness. With low brightness level grayscale goes totally green. I think I'll try to implement some callback for brightness changes in mdnie in kernel and apply some color correction there. Have no idea, how I'm gonna do that, but I'll try.
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Orphee said:
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Click to expand...
Click to collapse
Well, thanks indeed, but what I'm saying is that I have no idea how to correlate values from ICC with mdnie values. I don't know what values in ICC profile mean, some kind of coordinates of base RGB colors on some colorspace. I don't know how to translate them into values like red-in-black, red-in-green, red-in-white.
That's what problem is.
If you know anything about ICC profile structure, if can somehow describe all that values to me, maybe then we could figure out something to do with all that.
heyjoe66 said:
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
Click to expand...
Click to collapse
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
lombartz said:
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
Click to expand...
Click to collapse
Nice. That looks really useful. Sadly, these wait_for_fb_* attributes are missing on our device, or maybe moved to some place else. Need to look for them.
Regarding the problem you're referring to, it's actually a bug in samsung's code. They are trying to read profile from /sdcard when sdcard is not ready yet. I've fixed it in my own kernel build by moving the mdnie folder to /data. So now profile is updated as it meant to.
Can this be used to raise the gamma levels on the sm-t805 lollipop screen?
I have been playing around with this today but cant seem to get it to affect the color.
I have loaded up ABD, and loaded the DYNAMIC_UI profile into your little app but none of the sliders seem to affect anything on screen.
This is on a T800 running Cyanogenmod
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Astania said:
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Click to expand...
Click to collapse
Nope, thats not what this is for. I have the same piece of hardware but it only creates a profile that other apps can use if they support the x-rite sdk, such apps are nonexistent on Android except the x-rite app itself, and that app only works for displaying photos.
The mDNIe profiles are going to bare zero relation to the x-rite profiles so you cant use the x-rite profiles system wide even if you had the means.
I dont think there is enough dev backing on this to make it happen, but the ultimate goal would be to create a tool which is able to adjust the various settings of these profiles so it can be used in conjunction with a colorometer to create a color accurate profile that can be loaded up system wide.
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Astania said:
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Click to expand...
Click to collapse
Yup, I completely agree with what you are saying.
The screen on the Galaxy Tab S is really great, a very capable screen. But it's hampered by being locked to the few profiles Samsung provides.
Unfortunately mDNIe is a Samsung-only affair, and the tool posted earlier is full of sliders that seem to do nothing to the colour of the screen.
The profiles created by the X-Rite app are just a correction on top of a correction, this is fine and all as the chances of us getting low-level calibration seem non-existent, but there are no apps out whatsoever that actually use the X-Rite sdk (other than the x-rite app).
Without an advanced developer on board who knows all of this stuff inside out, I dont think we are going to get anywhere with conversion of mDNIe to ICC or anything like this.
The X-Rite app is great for photos, if there was any support for the X-Rite SDK in a video app this would be a good enough solution for me even if it is a correction on top of a correction, as colour accuracy in the OS is not important.

How do I call the device driver functions from JNI folder

I have a Java Native Interface project that works. It is the helloJNI prototype. Now I want to use it to call the functions in the header file of a Device Driver. This DD is already in my image, and I see it in /dev folder. What I want to know if how do I call the device driver functions? Here is what I have in my JNI folder:
Code:
#include "com_example_sansari_usedevicedriver_MainActivity.h"
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
/*
* Class: com_example_sansari_usedevicedriver_MainActivity
* Method: useqseecom
* Signature: ()Ljava/lang/String;
*/
JNIEXPORT jstring JNICALL Java_com_example_sansari_usedevicedriver_MainActivity_UseQUALCOM
(JNIEnv *env, jobject obj)
{
(*env)->NewStringUTF(env,"Hi From UseDeviceDriver");
}
Below is the executable I created to interface with the device driver from the user space. It works. I am trying to see how do I add the code below to the JNI handle I have above. Where does the main function of my executable below fit in the above file?
[/CODE]
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char **argv)
{
/* Our file descriptor */
int fd;
int rc = 0;
char *rd_buf[16];
printf("<1>%s: entered\n", argv[0]);
/* Open the device */
fd = open("/dev/hello1", O_RDWR);
if ( fd == -1 ) {
perror("<1>open failed");
rc = fd;
exit(-1);
}
printf("<1>%s: open: successful\n", argv[0]);
/* Issue a read */
rc = read(fd, rd_buf, 0);
if ( rc == -1 ) {
perror("<1>read failed");
close(fd);
exit(-1);
}
printf("<1>%s: read: returning %d bytes!\n", argv[0], rc);
close(fd);
return 0;
}
[/CODE]

toolbox.c -- struct - define toolname - tool.h <==== please help me learn this!

Updated with answer: (not sure how much of this is actually needed but it gets you playing with your own custom Android 6.01 Toolbox!)
Trying to compile toolbox.c for some odd reason? Or bionic? Or the libc libraries, all this section of code is super easy.
1. I downloaded the AOSP that matched the build number of the sources for my device
2. I download the sources for my device and merged them in as described in the text file. (basically replace don't merge)
3. I copied in my device specific hardware I found from the AP file of my firmware.
4. I follow instructions both on the AOSP site and on this forum to prepare my platform for building. (stole some settings from cyanogenmod real quick)
5. make modules <==== list of modules
6. make toolbox
words
https://android.googlesource.com/platform/system/core/+/master/toolbox
Here's the code that's stumping me (compiler can't find tools.h and neither can I) It seems to be created on the fly but how does it do it?
Code:
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define TOOL(name) int name##_main(int, char**);
#include "tools.h"
#undef TOOL
static struct {
const char* name;
int (*func)(int, char**);
} tools[] = {
#define TOOL(name) { #name, name##_main },
#include "tools.h"
#undef TOOL
{ 0, 0 },
};
Here's toolbox.c Google Source
https://android.googlesource.com/platform/system/core/+/master/toolbox/toolbox.c

Do anyone know about this log ? (RILQ/RILD log)

My V20(US996) can't connect mobile cellular data. I use the V20 on CDMA EVDO Network.
The logcat is shown this log when connect mobile data network.
04-06 15:39:11.841 1552 1706 E RILQ : (0/1552): RIL[0][main] qcril_data_set_ril_profile_id: RIL provided [3] profile id. This is currently not supported
04-06 15:39:11.863 1552 1706 E RILQ : (0/1552): RIL[0][main] qcril_data_request_setup_data_call: unable to setup data call, index [0]
04-06 15:39:11.863 1552 1706 E RILQ : (0/1552): RIL[0][main] qcril_data_request_setup_data_call: qcril_data_request_setup_data_call: EXIT with FAILURE
What is mean?
How can I solve the problem?
Please give help everyone. Thanks. Have a nice day!
reference this for code ( 3)
Code:
ypedef enum {
RIL_E_SUCCESS = 0,
RIL_E_RADIO_NOT_AVAILABLE = 1, /* If radio did not start or is resetting */
RIL_E_GENERIC_FAILURE = 2,
RIL_E_PASSWORD_INCORRECT = 3, /* for PIN/PIN2 methods only! */
RIL_E_SIM_PIN2 = 4, /* Operation requires SIM PIN2 to be entered */
RIL_E_SIM_PUK2 = 5, /* Operation requires SIM PIN2 to be entered */
RIL_E_REQUEST_NOT_SUPPORTED = 6,
RIL_E_CANCELLED = 7,
RIL_E_OP_NOT_ALLOWED_DURING_VOICE_CALL = 8, /* data ops are not allowed during voice
call on a Class C GPRS device */
RIL_E_OP_NOT_ALLOWED_BEFORE_REG_TO_NW = 9, /* data ops are not allowed before device
registers in network */
RIL_E_SMS_SEND_FAIL_RETRY = 10, /* fail to send sms and need retry */
RIL_E_SIM_ABSENT = 11, /* fail to set the location where CDMA subscription
shall be retrieved because of SIM or RUIM
card absent */
RIL_E_SUBSCRIPTION_NOT_AVAILABLE = 12, /* fail to find CDMA subscription from specified
location */
RIL_E_MODE_NOT_SUPPORTED = 13, /* HW does not support preferred network type */
RIL_E_FDN_CHECK_FAILURE = 14, /* command failed because recipient is not on FDN list */
RIL_E_ILLEGAL_SIM_OR_ME = 15 /* network selection failed due to
illegal SIM or ME */
} RIL_Errno;
typedef enum {
RIL_CALL_ACTIVE = 0,
RIL_CALL_HOLDING = 1,
RIL_CALL_DIALING = 2, /* MO call only */
RIL_CALL_ALERTING = 3, /* MO call only */
RIL_CALL_INCOMING = 4, /* MT call only */
RIL_CALL_WAITING = 5 /* MT call only */
} RIL_CallState;
typedef enum {
RADIO_STATE_OFF = 0, /* Radio explictly powered off (eg CFUN=0) */
RADIO_STATE_UNAVAILABLE = 1, /* Radio unavailable (eg, resetting or not booted) */
RADIO_STATE_SIM_NOT_READY = 2, /* Radio is on, but the SIM interface is not ready */
RADIO_STATE_SIM_LOCKED_OR_ABSENT = 3, /* SIM PIN locked, PUK required, network
personalization locked, or SIM absent */
RADIO_STATE_SIM_READY = 4, /* Radio is on and SIM interface is available */
RADIO_STATE_RUIM_NOT_READY = 5, /* Radio is on, but the RUIM interface is not ready */
RADIO_STATE_RUIM_READY = 6, /* Radio is on and the RUIM interface is available */
RADIO_STATE_RUIM_LOCKED_OR_ABSENT = 7, /* RUIM PIN locked, PUK required, network
personalization locked, or RUIM absent */
RADIO_STATE_NV_NOT_READY = 8, /* Radio is on, but the NV interface is not available */
RADIO_STATE_NV_READY = 9 /* Radio is on and the NV interface is available */
} RIL_RadioState;
typedef enum {
RADIO_TECH_UNKNOWN = 0,
RADIO_TECH_GPRS = 1,
RADIO_TECH_EDGE = 2,
RADIO_TECH_UMTS = 3,
RADIO_TECH_IS95A = 4,
RADIO_TECH_IS95B = 5,
RADIO_TECH_1xRTT = 6,
RADIO_TECH_EVDO_0 = 7,
RADIO_TECH_EVDO_A = 8,
RADIO_TECH_HSDPA = 9,
RADIO_TECH_HSUPA = 10,
RADIO_TECH_HSPA = 11,
RADIO_TECH_EVDO_B = 12,
RADIO_TECH_EHRPD = 13,
RADIO_TECH_LTE = 14,
RADIO_TECH_HSPAP = 15 // HSPA+
} RIL_RadioTechnology;
// Do we want to split Data from Voice and the use
// RIL_RadioTechnology for get/setPreferredVoice/Data ?
typedef enum {
PREF_NET_TYPE_GSM_WCDMA = 0, /* GSM/WCDMA (WCDMA preferred) */
PREF_NET_TYPE_GSM_ONLY = 1, /* GSM only */
PREF_NET_TYPE_WCDMA = 2, /* WCDMA */
PREF_NET_TYPE_GSM_WCDMA_AUTO = 3, /* GSM/WCDMA (auto mode, according to PRL) */
PREF_NET_TYPE_CDMA_EVDO_AUTO = 4, /* CDMA and EvDo (auto mode, according to PRL) */
PREF_NET_TYPE_CDMA_ONLY = 5, /* CDMA only */
PREF_NET_TYPE_EVDO_ONLY = 6, /* EvDo only */
PREF_NET_TYPE_GSM_WCDMA_CDMA_EVDO_AUTO = 7, /* GSM/WCDMA, CDMA, and EvDo (auto mode, according to PRL) */
PREF_NET_TYPE_LTE_CDMA_EVDO = 8, /* LTE, CDMA and EvDo */
PREF_NET_TYPE_LTE_GSM_WCDMA = 9, /* LTE, GSM/WCDMA */
PREF_NET_TYPE_LTE_CMDA_EVDO_GSM_WCDMA = 10, /* LTE, CDMA, EvDo, GSM/WCDMA */
PREF_NET_TYPE_LTE_ONLY = 11 /* LTE only */
} RIL_PreferredNetworkType;
/* Source for cdma subscription */
typedef enum {
CDMA_SUBSCRIPTION_SOURCE_RUIM_SIM = 0,
CDMA_SUBSCRIPTION_SOURCE_NV = 1
} RIL_CdmaSubscriptionSource;
/* User-to-User signaling Info activation types derived from 3GPP 23.087 v8.0 */
typedef enum {
RIL_UUS_TYPE1_IMPLICIT = 0,
RIL_UUS_TYPE1_REQUIRED = 1,
RIL_UUS_TYPE1_NOT_REQUIRED = 2,
RIL_UUS_TYPE2_REQUIRED = 3,
RIL_UUS_TYPE2_NOT_REQUIRED = 4,
RIL_UUS_TYPE3_REQUIRED = 5,
RIL_UUS_TYPE3_NOT_REQUIRED = 6
} RIL_UUS_Type;
/* User-to-User Signaling Information data coding schemes. Possible values for
* Octet 3 (Protocol Discriminator field) in the UUIE. The values have been
* specified in section 10.5.4.25 of 3GPP TS 24.008 */
typedef enum {
RIL_UUS_DCS_USP = 0, /* User specified protocol */
RIL_UUS_DCS_OSIHLP = 1, /* OSI higher layer protocol */
RIL_UUS_DCS_X244 = 2, /* X.244 */
RIL_UUS_DCS_RMCF = 3, /* Reserved for system mangement
convergence function */
RIL_UUS_DCS_IA5c = 4 /* IA5 characters */
} RIL_UUS_DCS;
/* User-to-User Signaling Information defined in 3GPP 23.087 v8.0
* This data is passed in RIL_ExtensionRecord and rec contains this
* structure when type is RIL_UUS_INFO_EXT_REC */
typedef struct {
RIL_UUS_Type uusType; /* UUS Type */
RIL_UUS_DCS uusDcs; /* UUS Data Coding Scheme */
int uusLength; /* Length of UUS Data */
char * uusData; /* UUS Data */
} RIL_UUS_Info;
/* CDMA Signal Information Record as defined in C.S0005 section 3.7.5.5 */
typedef struct {
char isPresent; /* non-zero if signal information record is present */
char signalType; /* as defined 3.7.5.5-1 */
char alertPitch; /* as defined 3.7.5.5-2 */
char signal; /* as defined 3.7.5.5-3, 3.7.5.5-4 or 3.7.5.5-5 */
} RIL_CDMA_SignalInfoRecord;

Categories

Resources