Hi rooted Xperia Play owners,
Could one of you post the output of 'cat /proc/bus/input/devices' (in a root shell) here?
I'm trying desperately to simulate the touchpad of it and the output of that command would (hopefully) help immensely.
Thanks in advance!
John
P.S. I think this seems more suited in Development, but I can't post there yet
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="msm_pmic_pwr_key"
P: Phys=semc_rpc_server_handset
S: Sysfs=/devices/virtual/input/input0
U: Uniq=
H: Handlers=kbd event0
B: EV=3
B: KEY=100800 0 0 0
I: Bus=0019 Vendor=0001 Product=0001 Version=0001
N: Name="keypad-pmic-zeus"
P: Phys=dev/keypad-pmic
S: Sysfs=/devices/i2c-6/6-0000/keypad-pmic.0/input/input1
U: Uniq=
H: Handlers=kbd event1
B: EV=3
B: KEY=100 0 0 0 0 2000000 0 40000800 40 0 0 0
I: Bus=0019 Vendor=0001 Product=0001 Version=0001
N: Name="keypad-game-zeus"
P: Phys=keypad-game-zeus/input0
S: Sysfs=/devices/i2c-6/6-0000/pm8058-keypad/input/input2
U: Uniq=
H: Handlers=kbd event2 keychord
B: EV=13
B: KEY=4000000 0 0 0 0 0 c0000 0 0 10000000
B: MSC=10
I: Bus=0018 Vendor=0001 Product=0001 Version=0001
N: Name="synaptics_touchpad"
P: Phys=dev/synaptics_touchpad
S: Sysfs=/devices/virtual/input/input3
U: Uniq=
H: Handlers=event3
B: EV=9
B: ABS=2730000 0
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="cy8ctma300_touch"
P: Phys=cy8ctma300_touch/input0
S: Sysfs=/devices/platform/spi_qsd.0/spi0.0/input/input4
U: Uniq=
H: Handlers=event4
B: EV=b
B: KEY=400 0 4 0 0 0 0 0 0 0 0
B: ABS=2610000 1000003
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="keypad-zeus"
P: Phys=
S: Sysfs=/devices/virtual/input/input5
U: Uniq=
H: Handlers=kbd event5 keychord
B: EV=33
B: KEY=db0000 0 4 0 0 0 1680 0 0 0
B: MSC=8
B: SW=1
I: Bus=0000 Vendor=0001 Product=0001 Version=0001
N: Name="bma150"
P: Phys=/sys/devices/i2c-0/0-0038
S: Sysfs=/devices/virtual/input/input6
U: Uniq=
H: Handlers=event6
B: EV=9
B: ABS=100 7
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="gp2ap002a00f"
P: Phys=
S: Sysfs=/devices/virtual/input/input7
U: Uniq=
H: Handlers=event7
B: EV=9
B: ABS=2000000
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="simple_remote"
P: Phys=
S: Sysfs=/devices/virtual/input/input8
U: Uniq=
H: Handlers=kbd event8
B: EV=3
B: KEY=7 4 0 0 0 0 0 0 0
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="simple_remote_appkey"
P: Phys=
S: Sysfs=/devices/virtual/input/input9
U: Uniq=
H: Handlers=event9
B: EV=3
B: KEY=8 0 0 0 0 0 0 0 0
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="compass"
P: Phys=
S: Sysfs=/devices/virtual/input/input10
U: Uniq=
H: Handlers=event10
B: EV=9
B: ABS=305bf
I: Bus=0003 Vendor=0000 Product=0000 Version=0004
N: Name="atdaemon"
P: Phys=
S: Sysfs=/devices/virtual/input/input11
U: Uniq=
H: Handlers=kbd event11 keychord
B: EV=b
B: KEY=400 0 70000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffff
f ffffffff
B: ABS=1000003
@OP:
synaptics touchpad @input3 is the game touchpad.
Sent from my R800i using XDA App
Both of you:
Thanks!
(now I just have to figure out how to use this...)
John
similar request could someone please post the output of:
'cat /proc/bus/input/handlers'
Rc-Blob said:
similar request could someone please post the output of:
'cat /proc/bus/input/handlers'
Click to expand...
Click to collapse
N: Number=0 Name=kbd
N: Number=1 Name=evdev Minor=64
N: Number=2 Name=keychord
Could you share some insight on what you're trying to accomplish?
Logseman said:
Could you share some insight on what you're trying to accomplish?
Click to expand...
Click to collapse
Sure thing.
Well as you probably know, minecraft came out for the xperia play a few days ago. Several people have tried it on other android devices only to find out that it requires the analogue nubs/pad on the Play for looking around and such...
So after digging around ont the Sony Ericsson dev site, I found out that the touch pad on the xperia play is just a standard touchpad, which android supports natively
So, I was just curious how the phone/android 'sees' the touchpad.
The long term goal is to create a virtual input device that reports itself as a touchpad to linux, meaning android should see it as a touchpad, meaning minecraft on every android phone
You might have realised a slight problem in my plan; namely where the hell do I get the input for the virtual touchpad from, well... The Dualshock3/SixAxis controller
I was going to try to get in contact with the devs for the sixaxis driver app that recently came out once I've got it up and running to see if they could incorporate it into their driver.
TL;DR: Simulate the touchpad of the xperia with the analog sticks from a PS3 controller
So, I guess I need to bruch up on the Linux Input subsystem.
Any thoughts, suggestions?
Sounds like alot of messing about another reason why i love my play
Sent from my R800i using Tapatalk
You may want to poke with this touchpad calibrator that a user here compiled from Sony's sources: http://forum.xda-developers.com/showthread.php?t=1045374
Mojang in a email to me said that the version for all android handset is due in about a month (that was said on release day) so don't stress too much.
Sent from my R800i using XDA App
Zoop57 said:
Mojang in a email to me said that the version for all android handset is due in about a month (that was said on release day) so don't stress too much.
Click to expand...
Click to collapse
That's good to hear
However, the curiosity bug has bitten me now so I must finish this
Rc-Blob said:
That's good to hear
However, the curiosity bug has bitten me now so I must finish this
Click to expand...
Click to collapse
Keep in mind that it's touchpad. So you have to think of a way to generate touch event only when analog stick would be moved, not when it's still.
How about marrying the default LatinIME keyboard and the touchpad please - I’d contribute to the bounty if someone organises that please. I think people do not realize how responsive and accurate is the touchpad and that placing any sticker on it does not make it registering at least two finger movements/touches on it any worse. Try http://forum.xda-developers.com/showthread.php?t=1045374
First imagine eliminating top 3 rows of the default keyboard with the touchpad for all the letters
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
including shift and backspace by PS triangle and square. Leaving only word suggestions and optionally some of the default bottom line of the on screen keyboard (as it dynamically changes punctuations to "@"/etc and enter key to "next"/"go"/etc depending on the content and allows other nice to have things but even some of that could be replaced by other PS keys and extra Menu button.
I think PS "X" and "Start" buttons easily remove the need for on screen Enter(Go/Next) but it could be optional to leave it on screen too, "Select" hardware button eliminates the need for on screen switch for numbers/symbols layout and will just pop up that keyboard on screen and vice versa. Therefore other grey buttons of the default on screen keyboard can go too.
If Circle button can be used instead of space bar (I understand that it acts as Back button but SE say that it is actually "Alt" modified one so PS "O" is detectable) we could have that freed up for word suggestion area if applicable. If we choose to leave the two punctuation keys currently to the right and left of the default keyboard's spacebar we would end up having them in the bottom two corners of the screen now but allow PS "Right" and "Left" shoulder buttons activate them too (i.e Right triggers “.”, Left triggers “,” or “@” in email mode, and the entire line between them on the screen would be for word suggestions or anything else we need... or leave empty as game pad and touch pad could replace on screen keyboard in landscape mode if we wanted without any of the soft keys on screen.
Vibration and zoomed in keys popup feedback on screen should stay the same as when using default on screen keyboard still.
I have not even thought about combos of the above with each other like Triangle(aka new Shift) together with Menu...
I understand that touch pad sample code and gingerbread keyboard source are freely available. Don’t know if detection of gamepad slide out state is a problem so that we can have keyboard switching to touchpad from onscreen automatically – hopefully it is part of the touchpad source or maybe “alt” key modifier. If someone makes it open source so that more people can contribute to and benefit from it. I will also be happy to donate some money for that.
That's a space too small for a keyboard. It's bad enough with the stock keyboard keys, in portrait it's hard to hit them correctly with your thumb, and it's a much bigger space. What's the use of that keyboard which has no signs (and obviously no space to add them in)? How would you go about using other languages aside of English? You can't even see the parts of the pad corresponding to each key...
I see more merit in transforming the touchpad into a sort of "trackball"-like mechanism, which allows us to take advantage of the swiping possibilities it has.
The touchpad area is very comparable with that of A to Z letters on blackberry in width and height. Each round pad on play easily accommodates 9 keys: 1 centre, 8 around (north, north east, east, etc). Middle part fits 3 keys at the top and same in the bottom row plus 2 in the middle. The sticker will label each letter and can have a bump give a feel feedback. I can even imagine a pressable bubble effect can be achieved with custom sticers but maybe some people will not like sliding over them during gameplay. But possibly bumps may be helpful in game play too. The amazing thing is that the touchpad responds to movements of up to two fingers at the time regardless of stickers on top of it.
I agree that total 26 A to Z keys this way are maybe not so good for languages with more keys but less used keys could be achievable with long press popup.
Agree with "trackball"-like mechanism to take advantage of swiping posibilities as per Logseman's post above but think it is totally coexistable with the rest of the touch keyboard.
How about using the optical trackball on most phones? Like the Desire
Not many phones have a trackball. I've seen it in the Desire, the Nexus One and some resistive tablets.
Related
Hello!
I recently purchased an iPaq hw6955 and fell in love with it. I have been coding on Windows for way too many years, yet this is the first time my PDA doesn't run Linux (or OpenBSD ).
I recently saw levenum's taskbar battery meter, and though that it would make a nice project for a first mobile application. How pleased I was when levenum accepted my request to share the sources. How even more pleased and surprised I was when I saw the code. It is exactly the same as coding on Windows...
So my idea was to have a fullscreen gradient bar that would look "behind" VistaBetaTWO's WA2 Aero skin. And I've done it (and it only weights 12 kb!).
Here is a screenshot for your viewing pleasure.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
But after having read levenum's thread, I understood some people would like it thinner, etc... So there are tons of options read from the registry! The gauge should work on WM 5.0 PocketPC and Smartphone editions, and should handle screen rotation, but I can't test this because the emulator doesn't have an option to switch between landscape and portrait, and the hw6955 is a square screen device.
The registry keys are kept for each resolution, which I will write as "W x H". (e.g. The base key for my device (240 x 240) would be HKCU\Software\VistaHide\Battery Gauge\240 x 240\). All of these keys are independant (i.e. If you need to only modify the height of the bar, you only need to create the Height key.)
Options :
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\X
- Window's left position. Default : 0.
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Y
- Window's top position. Default : 0.
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Width
- Window's width. Default : -1.
- Note: Any value below 0 means fullscreen.
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Height
- Window's height. Default : 4.
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Thresholds\Critical
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Thresholds\Low
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Thresholds\High
- Value between 0 and 100 which represents the gradient thresholds.
- Default : (Critical) 0.05, (Low) 0.25, (High) 1.00.
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Background\Light
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Background\Normal
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Background\Dark
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Critical\Light
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Critical\Normal
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Critical\Dark
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Low\Light
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Low\Normal
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\Low\Dark
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\High\Light
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\High\Normal
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Colors\High\Dark
- Colors! If you look closely at the screenshot, you will see that the bar is "beleveled". The light color is the top part, and dark one the bottom, everything in between is normal. Want to disable "beleveling" ? Set the light, normal and dark to the same color.
- Default values ( Light, Normal, Dark ) :
Background : RGB ( 64, 64, 64 ), RGB ( 32, 32, 32 ), RGB ( 0, 0, 0 )
Critical : RGB ( 255, 127, 127 ), RGB ( 255, 0, 0 ), RGB ( 127, 0, 0 )
Low : RGB ( 255, 255, 127 ), RGB ( 255, 255, 0 ), RGB ( 127, 127, 0 )
High : RGB ( 127, 255, 127 ), RGB ( 0, 255, 0 ), RGB ( 0, 127, 0 )
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Excluded Regions\{Anything}\X
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Excluded Regions\{Anything}\Y
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Excluded Regions\{Anything}\Width
[DWORD] HKCU\Software\VistaHide\Battery Gauge\W x H\Excluded Regions\{Anything}\Height
- Now for the fun part... This is how you can remove "parts" of the bar. For every key in "Excluded Regions", it will read a rectangle, and exclude it from the window.
- Default value : No excluded regions.
Example (I think it's necessary ) :
Here are the keys needed to achieve the look in the screenshot (at 240 x 240). It uses all the default values, except for 4 excluded regions (one per line).
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 1\X : (DWORD) 13
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 1\Y : (DWORD) 0
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 1\Width : (DWORD) 11
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 1\Height : (DWORD) 1
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 2\X : (DWORD) 11
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 2\Y : (DWORD) 1
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 2\Width : (DWORD) 15
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 2\Height : (DWORD) 1
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 3\X : (DWORD) 10
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 3\Y : (DWORD) 2
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 3\Width : (DWORD) 17
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 3\Height : (DWORD) 1
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 4\X : (DWORD) 9
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 4\Y : (DWORD) 3
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 4\Width : (DWORD) 19
HKCU\Software\VistaHide\Battery Gauge\240 x 240\Excluded Regions\Line 4\Height : (DWORD) 1
EDIT: Forgot one neat feature... If you launch it while it is already running, it will close the running instance.
Hope you enjoy, and you can expect a lot more freebies like this from me in the future!
Looks damn pretty!
Gonna check it out right away!
Molski
Awesome post. Thanks so much for this.
Great tutorial as well, I succesfully (and easily) adjusted my height to 2 which is a lot less intrusive for my needs. ;-)
Glad you find it useful. For those who intend to use it on a device that can rotate the screen, I remembered while commuting home that I forgot to regenerate the bitmaps on rotation. This means that the bar will not be drawn correctly upon rotation. I will fix this in the next version.
And if I feel like it, I might even make another application to configure it (to keep the bar's small footprint.)
Awesome application... thanks u very much...
i have already download and try it... however why my bar always shown in front of my wisbar not behind the wisbar ?
Have i do anything wrong ??
ins0mniaque said:
this is the first time my PDA doesn't run Linux
Click to expand...
Click to collapse
We are working on it
http://wiki.xda-developers.com/index.php?pagename=Ipaq6915
mugen_jon said:
Awesome application... thanks u very much...
i have already download and try it... however why my bar always shown in front of my wisbar not behind the wisbar ?
Have i do anything wrong ??
Click to expand...
Click to collapse
The bar is not "behind" the wisbar. It is simply not drawn at some places. To achieve the same looks as in the screen shot, the you need the 16 registry values I posted in the section "Here are the keys needed to achieve the look in the screenshot (at 240 x 240). It uses all the default values, except for 4 excluded regions (one per line).".
hi, i tried it on my T-Mobile SDA WM5 smartphone but nothing happened. There was also no HKCU registry entries.
oldsap said:
hi, i tried it on my T-Mobile SDA WM5 smartphone but nothing happened.
Click to expand...
Click to collapse
Sorry, my bad! I blatantly assumed the smartphone edition was like the PocketPC edition. I will fix this in the next version. Probably friday afternoon.
oldsap said:
There was also no HKCU registry entries.
Click to expand...
Click to collapse
I might have been a little bit too implicit. HKCU stands for HKEY_CURRENT_USER. All those keys do not exist, and they are not created by the program. The bar will attempt to read those values on start, and will fall back to the default value if the key doesn't exist. For exemple, if you only create the "HKCU\Software\VistaHide\Battery Gauge\W x H\Height" key, then only the Height of the bar will be modified, nothing else.
ins0mniaque said:
Sorry, my bad! I blatantly assumed the smartphone edition was like the PocketPC edition. I will fix this in the next version. Probably friday afternoon.
Click to expand...
Click to collapse
Thank you. will be eagerly waiting for it
I might have been a little bit too implicit. HKCU stands for HKEY_CURRENT_USER. All those keys do not exist, and they are not created by the program. The bar will attempt to read those values on start, and will fall back to the default value if the key doesn't exist. For exemple, if you only create the "HKCU\Software\VistaHide\Battery Gauge\W x H\Height" key, then only the Height of the bar will be modified, nothing else.
Click to expand...
Click to collapse
thanks for the clear up
anyone get it to automatically adjust when going from portrait to landscape?
New version
I just found version 1.1.1 at http://www.freewarepocketpc.net/ppc-download-vistahide-battery-gauge-v1-1-1.html
Is this the same program but the upgraded version just never got posted here?
Anyway, it works great on my cingular/at&t 8525 aka HTC hermes in landscape AND portrait mode.
http://www.freewarepocketpc.net/mirror/VistaHide%20Battery%20Gauge%201.1.1%20WM5%20Pocket%20PC.zip
I know this is an old post but I've been trying to get this off my mogul for a while now. Somehow it's gotten to my startup folder and I've tried everything to delete it.
Any suggestions?
Thanks.
vicn77 said:
I know this is an old post but I've been trying to get this off my mogul for a while now. Somehow it's gotten to my startup folder and I've tried everything to delete it.
Any suggestions?
Thanks.
Click to expand...
Click to collapse
From the 1st post
"EDIT: Forgot one neat feature... If you launch it while it is already running, it will close the running instance."
Take care it isn't active. Then uninstall it!
tried that also, total commander says its unable to delete the file.
so i just had it inactive and moved it out of the startup folder.
vicn77 said:
tried that also, total commander says its unable to delete the file.
so i just had it inactive and moved it out of the startup folder.
Click to expand...
Click to collapse
Change the attribute of the file!
WOWIEE!
Do i really need to install the sources too ?
And would it be nice to have a little tool, to set up the height and stuff you really need..
ThnX, looks pretty neat btw. Cool app man.
mazterjay said:
Do i really need to install the sources too ?
And would it be nice to have a little tool, to set up the height and stuff you really need..
Click to expand...
Click to collapse
Dogfoods tweak can set the height of the statusbar, and more.
Does not reload on Power off
I am running WM6 on an AT&T Tilt. The program runs fine (and I find it extremely helpful...well done). For some reason, when I turn the phone off and restart it, the Battery Bar does not reload. I have to restart it every time. Any thoughts?
Thanks in advance, both for the help and for creating a wonderful little program.
DJ
put the program inside your windows/start folder...
and it will start each time...
I'm struggling to build up a Tasker routine to automate the USB Audio setup with one screen tap.
To do that I need a method for emulating screen taps (like for "off" and "host" and "close" in the USB Mode Utility, for example). I've already discovered that Eclair lacks the shell command "input tap x y". That would have been the easy route.
I'm not sure about "sendevent" and I'm even less sure about the syntax. Every resource I look at seems written for people who already know the answer. The typical syntax seems to be something like
sendevent /dev/input/event2 x x x
I can see in the root directory that there is a dev folder and in that an input folder. In there are listed 5 things:
21:14 event0
21:14 event1
21:14 event2
21:14 mice
21:14 mouse0
Does anyone know if "sendevent" is a valid shell command in Eclair and, if so, the functions of the events listed above?
Edit: well, I have a partial answer. Running an adb shell getevent I found the following:
event2 = zForce Touchscreen
event1 = gpio-keys [hardware, I assume?)
event0 = TWL4030 Keypad
It said it could not find a driver version for mice or mouse0 because it was not a typewriter (duh).
So it looks like event2 is what I need to deal with. Now if I only understood how. I know I need the screen coordinates where the touch is to be emulated
and I have an app for that.
As much as I love UsbMode, you don't need it.
For a script, you are better off just doing what it does yourself.
Code:
echo host > /sys/devices/platform/musb_hdrc/mode
echo peripheral > /sys/devices/platform/musb_hdrc/mode
echo 0 > /sys/devices/platform/bq24073/force_current
echo 500000 > /sys/devices/platform/bq24073/force_current
Renate NST said:
As much as I love UsbMode, you don't need it.
For a script, you are better off just doing what it does yourself.
Code:
echo host > /sys/devices/platform/musb_hdrc/mode
echo peripheral > /sys/devices/platform/musb_hdrc/mode
echo 0 > /sys/devices/platform/bq24073/force_current
echo 500000 > /sys/devices/platform/bq24073/force_current
Click to expand...
Click to collapse
Wow, and I was so excited because I figured out how to use sendevent w/Tasker to "press" the OFF button in the USB Mode Utility app today!
I really appreciate your response, Renate, so please bear with my lack of Android understanding. I can see that the first line is equivalent to tapping "host" (at least I hope that's what it is...). The the second is how to get back to normal mode.
By extension I am guessing that the third line is equivalent to "off" while the last line is equivalent to "auto". Right so far?
Now the most important question: so is "echo" a shell command I can use? I looked it up and it appears to be, just want to check before I try typing that into Tasker (not that it's half as bad as 8 sendevents to "touch" the screen one time!).
And one last question: is there a similar command equivalent to the "beep" of AudioCTRL (i.e., to kickstart the audio)
Edit: oh, wait, this is it, isn't it: kill -9 19409 [that being the PID of mediaserver on my NST]
Thanks for your help!
Woo-Hoo!!
The shell commands from Renate work great in a simple toggle Task. I just need to work on a few wait times and it's a done deal. One-touch USB Audio!
One question: the command "echo 500000 > /sys/devices/platform/bq24073/force_current" leaves the Max. current setting at 500 mA rather than "Auto". I'm guessing since there is nothing attached to the USB port anyway when you're all done that this is OK?
@nmyshkin
Values are 0, 100000, 500000, 1500000, auto for off, 100mA, 500mA, 1.5A, auto
Renate NST said:
@nmyshkin
Values are 0, 100000, 500000, 1500000, auto for off, 100mA, 500mA, 1.5A, auto
Click to expand...
Click to collapse
Perfect! Thanks so much. I've got a little widget on my homescreen now that does the work behind the scenes! Still struggling with a shortcut that I could customize a little.
I looked at the App Creator for Tasker but see that it requires Android 2.3. I wonder if created apps would therefore be for 2.3 or up? If not, I'd install it on my Nook Tablet running CM 10.2, make an app and export it. That would be cool.
Edit: both completed. Tasker widget here, stand-alone apps here.
Digging up an old thread here, but I'm trying to figure out a way to use an 'input tap' type event for my nook touch. I've got everything set up for a digital picture frame that can dynamically load images but the only slideshow viewer that I found to work doesn't start automatically, it loads on a file location menu first and I need to manually start the slideshow with a button press. Is there an 'input tap' equivalent that will work with the nook?
Figured it out. The adb shell command getevent will return a series of commands when you touch the screen (make sure it is a simple touch and not multiple points). Use these results (converting your numbers from hex to dec) as the command, in my case the correct sequence was:
sendevent /dev/input/event2 3 0 509
sendevent /dev/input/event2 3 1 58
sendevent /dev/input/event2 1 330 1
sendevent /dev/input/event2 0 0 0
sendevent /dev/input/event2 1 330 0
sendevent /dev/input/event2 0 0 0
Obviously it will be different for you, but the general sequence is x coordinate, y coordinate, touch screen, blank, release touch, blank.
And it works (i'm using a series of tasker adb shell commands)!
I don't know which viewer you are using (or even anything about them), but I'll be that it can take a path as data in the actuating Intent.
Then you'd only need something like:
Code:
am start -n com.neatoh.viewer/.Viewer -e Path /MyPhotos
No, these are all hypothetical values.
SEE UPDATE BELOW
After doing some more digging on surfaceflinger, atd, and their related libs, I found some interesting entries in a "strings" analysis of libinputflinger.so. Loads of stuff on touch calibration. I noticed some repeated strings that looked like they're assigned to different properties. You can see this clearly by entering:
Code:
strings /system/lib/libinputflinger.so | grep -iE '(^touch\.|[ ][ ]touch\.)'| sed -e 's/^[ \t]*//' | sort -n | uniq
The terminal returns
Code:
touch.coverage.calibration
touch.coverage.calibration: box
touch.coverage.calibration: none
touch.deviceType
touch.distance.calibration
touch.distance.calibration: none
touch.distance.calibration: scaled
touch.distance.scale
touch.distance.scale: %0.3f
touch.gestureMode
touch.orientation.calibration
touch.orientation.calibration: interpolated
touch.orientation.calibration: none
touch.orientation.calibration: vector
touch.orientationAware
touch.pressure.calibration
touch.pressure.calibration: amplitude
touch.pressure.calibration: none
touch.pressure.calibration: physical
touch.pressure.scale
touch.pressure.scale: %0.3f
touch.size.bias
touch.size.bias: %0.3f
touch.size.calibration
touch.size.calibration: area
touch.size.calibration: box
touch.size.calibration: diameter
touch.size.calibration: geometric
touch.size.calibration: none
touch.size.isSummed
touch.size.isSummed: %s
touch.size.scale
touch.size.scale: %0.3f
touch.wake
I looked up some of strings on the net, and lo and behold, they're build.prop entries! You can see the props above that have different strings to assign to them. The ones with a "%0.3f" refer to a number value, and the one with "%s" is a boolean 0/1.
I've only done a little testing, but I found a baseline of improvement values to make our touch screens more responsive. Some of the properties I couldn't find info on, so I'm testing some values like touch.distance.scale. I feel like I have definitely noticed improvements though. I'm no longer so pissed off using my phone, and the frequency of misses overall seems significantly lower. It's acceptable now. Here's what I'm using now at the end of my build.prop:
Code:
##### touch ######
touch.deviceType=touchScreen
# (geometric, diameter, box, area)
touch.size.calibration=geometric
touch.size.scale=100
# (amplitude, physical, none)
touch.pressure.calibration=amplitude
touch.pressure.scale=0.1
touch.gestureMode=pointer
# (interpolated, vector, none)
touch.orientation.calibration=interpolated
# (box, none)
touch.coverage.calibration=box
For detailed information on these touch properties, read here(search for the property you're interested in; the page is pretty long). Some are self-explanatory and others we'll just need to test more. Check them out and see if any calibration values make a significant change. Just copy the above code and paste to the bottom of /system/build.prop with a nice file manager like Solid Explorer. Warning: Adding these entries in the build.prop will change the default touch properties. You can always change them back to stock by removing or commenting the entries from build.prop. I assume most values are aafe, but I can't be sure.
Also worth noting. I found some additional build.prop values to make Android snappier. The fling/swipe velocity make a big difference. Not sure what the others correlate to.
Code:
##### touch related #####
view.touch_slop=2
view.scroll_friction=1.5
view.minimum_fling_velocity=25
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.min_pointer_dur=8
windowsmgr.max_events_per_sec=200
EDIT: For detailed information on these touch properties, read here.
I'm gonna add some "profiles" of touch settings to use down here.
This one is for a Nexus 4 I believe. I'm trying it out now, and it seems pretty good. My goal is to emulate the touch experience I had with that phone.
Code:
##### touch ######
touch.deviceType=touchScreen
touch.orientationAware=1
# (geometric, diameter, box, area)
touch.size.calibration=diameter
touch.size.scale=10
touch.size.bias=0
touch.size.isSummed=0
# (amplitude, physical, none)
touch.pressure.calibration=amplitude
touch.pressure.scale=0.005
touch.gestureMode=pointer
# (interpolated, vector, none)
touch.orientation.calibration=none
UPDATE
Hey guys, so here's an update to what I've found out about the touch screen and its issues. I apologize for my low activity on xda. I've been real busy working on some linux projects.
First, in order for the touch.* settings to work, they need to be put in an .idc (input device configuration) file with the name of the device. For the G4, that is: /system/usr/idc/touch_dev.idc.
If you have another phone or want to check, you can get the name of your touch screen device with the terminal command:
Code:
for i in /dev/input/event*; do j="$(getevent -i $i | grep -i touch)"; j=${j#*name: }; [[ -z $j ]] || echo ${j//\"/}; done
Before you go try out the .idc file, I want to warn you that certain settings will disable the touch screen. If this happens, you'll need to use adb to delete or move /system/usr/idc/touch_dev.idc somewhere else so that it doesn't get loaded when the phone boots. These are some settings you must NOT change in the .idc file:
Code:
touch.deviceType = touchScreen
touch.coverage.calibration = box
These are the settings I'm currently using:
Code:
touch.deviceType = touchScreen
touch.orientationAware = 1
touch.size.calibration = diameter
touch.size.scale = 1
touch.size.bias = 0
touch.size.isSummed = 0
touch.pressure.calibration = physical
touch.pressure.scale = 0.001
touch.orientation.calibration = none
touch.distance.calibration = none
touch.distance.scale = 0
touch.coverage.calibration = box
touch.gestureMode = spots
MultitouchSettleInterval = 1ms
MultitouchMinDistance = 1px
TapInterval = 1ms
TapSlop = 1px
I'm not sure if the Multitouch* and Tap* settings work or if adding more values from libinputflinger will work. There's little documentation on using settings that don't begin with "touch." You might have to do some experimentation and try other entries in the "strings /system/lib/libinputflinger.so" readout. I would also try using the first settings I posted if these don't seem to help.
Another thing I found out is that this phone performs better with low entropy. You can monitor your current entropy level in the terminal:
Code:
watch "cat /proc/sys/kernel/random/entropy_avail"
It's usually around 2000+ and peaks at 4096 with high activity which is where I think lag comes in. I found that lowering it to under 1000 average cut out the lag spikes I was getting:
Code:
echo 16 > /proc/sys/kernel/random/read_wakeup_threshold
echo 16 > /proc/sys/kernel/random/write_wakeup_threshold
I went ahead and added that to an init.d script. This doesn't have any side effects I've noticed besides possible increased battery life, since the "hwrng" process that generates entropy has no work to do. In case you don't have init.d, make sure busybox is installed, run this command in the terminal, and you'll have init.d startup:
Code:
mount -o remount,rw /system; echo "sleep 300 && run-parts /system/etc/init.d" >> /system/etc/init.qcom.post_boot.sh; mount -o remount,ro /system
One last thing to mention. The touch device has a little section in sysfs under: /sys/devices/virtual/input/lge_touch. There's some interesting information you can find there, values you can change, and tests you can run. Any file with a name ending in "test" can be run by opening the file, yes sysfs files are weird like this. All tests pass for me except "abs_test":
Code:
cat /sys/devices/virtual/input/lge_touch/abs_test
> ========RESULT=======
> Absolute Sensing Short Test : RESULT: Fail
> Absolute Sensing Open Test : RESULT: Fail
I haven't seen other people with or without touch screen issues run this test, so it may or may not be an indicator that something's wrong with the touch screen or its kernel-side drivers. By the way, this doesn't require superuser. You can check this on any device and even use a good text editor like QuickEdit to open the file and generate test results.
At this point, I'm fairly content with the new improvements I've made, but my best bet on a complete fix would be upgraded touch drivers. The "Advanced In-Cell Touch" device this phone uses is pretty new. There's a good chance this technology has drivers that don't have all the bugs worked out. This is something we'll have to wait on. On the other hand, if LGE handed over a bootloader unlock method and some source files, I'd be just fine with that too.
What "issues" is this attempting to fix
kyle1867 said:
What "issues" is this attempting to fix
Click to expand...
Click to collapse
Probably the horrible touch response many users experience.
Is this something that we can copy and paste into the end of the build prop, or is it replacing stuff that is already there?
Sent from my LG-H811 using XDA Free mobile app
Wow nice job man.
Is it possible to address the swipe registering as taps through this or do you think this will also address it?
Harmtan2 said:
Is this something that we can copy and paste into the end of the build prop, or is it replacing stuff that is already there?
Sent from my LG-H811 using XDA Free mobile app
Click to expand...
Click to collapse
You'll have to add almost all of them.
Yes bro am too facing the touch problem in my intex aqua star power. The problem is when we keep the finger the screen shakes and also in 100% of my usage 20% touch mismatches . On first i irritated and now i habituated with this touch. [emoji28]
Sent from my Aqua Star Power using Tapatalk
The build.prop edits seem to be making the difference. ?
Sent From My LG G4
Rydah805 said:
The build.prop edits seem to be making the difference. ?
Sent From My LG G4
Click to expand...
Click to collapse
would you say that double tap to wake is improved as well?
esmenikmatixx said:
would you say that double tap to wake is improved as well?
Click to expand...
Click to collapse
Hmm, you know what, it is.
Sent From My LG G4
esmenikmatixx said:
would you say that double tap to wake is improved as well?
Click to expand...
Click to collapse
I would say so I have all these except the new ones he posted an an script from another post an I do see some improvements defiantly double tap to wake
GUGUITOMTG4 said:
You'll have to add almost all of them.
Click to expand...
Click to collapse
Soooo... can you run through this with me? I'm not a novice but I'm trying to figure out how to add them? I can't simply text edit the build.prop on my phone or pull/push from my computer?
This post is the reason why I'm glad we now have root.
Akomack said:
Soooo... can you run through this with me? I'm not a novice but I'm trying to figure out how to add them? I can't simply text edit the build.prop on my phone or pull/push from my computer?
Click to expand...
Click to collapse
Yes, you can manually edit it and or push pull it, but sometimes it causes bootloop when edited as a plain text. I would suggest using a build prop editor app from Play Store (I use Build Prop Editor by JRummy. It's Also built in in Rom Toolbox). You will have to copy-paste line by line. I'm gonna try those settings, but in my case, my screen sometimes misses when the phone gets hot. I attribute my touchscreen issues to the Lag LG injected on thermal files.
GUGUITOMTG4 said:
Yes, you can manually edit it and or push pull it, but sometimes it causes bootloop when edited as a plain text. I would suggest using a build prop editor app from Play Store (I use Build Prop Editor by JRummy. It's Also built in in Rom Toolbox). You will have to copy-paste line by line. I'm gonna try those settings, but in my case, my screen sometimes misses when the phone gets hot. I attribute my touchscreen issues to the Lag LG injected on thermal files.
Click to expand...
Click to collapse
Do you have to be rooted to do that?
Hendrycks said:
Do you have to be rooted to do that?
Click to expand...
Click to collapse
Yes you do
Sent from my LG-H811 using Tapatalk
Hi,
yesterday I bought a G4 H815.
I have the following problem: If my phone is on the bed next to me, or lying on a table, the touchscreen response is terrible. If I'm holding it in my hand, there's no problem. If it's charging and so lying on the bed, there's no problem either.
I took a few photos with my Optimus Black, since I could't take any screenshots of the issue:
this is with my phone lying on the bed:
and here holding it in my hands, producing no problems at all.
what is this? It's bloody annonying and totally unacceptable from a phone of this level, And yes... I would use it without holding it, just placing it on my bed next to me, but you can see how it is performing like so...
is my display faulty, or what?
Thanks man.
It's indeed more responsive. Especially double tap to wake is working good now.
*justintime* said:
Thanks man.
It's indeed more responsive. Especially double tap to wake is working good now.
Click to expand...
Click to collapse
I didnt feel a difference can you post a screenshot of your buildprop? Thanks in advance
Maybe im doing it wrong
Sent from my LG-H811 using Tapatalk
Just edit with es file Explorer.
And get the build.prop in the system folder. Not the other one.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Every one of the RAW images I've taken with this device, regardless of the camera app, produces a dark line on the far right when viewed in Lightroom and Photoshop. Anyone else experience this? I've tried more than one manual camera app with the same result, but it does seem that the Snapseed app can see and edit the DNG on the phone without the green line present. Leads me to believe this is some kind of issue with Adobe so just wondered if anyone else had encountered it. I also tried disabling any import presets but that didn't change anything. Have a look at the attached samples to see what I mean.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I have encountered it, but I have not tried to fix it. Sorry.
I am also not convinced it is an Adobe issue. Open some of the DNGs in explorer, they should be around 25 megabytes give or take. But I often see them as low as 2 kilobyes, obviously that isn't right so there must be something else along the chain wrong.
staticx57 said:
I have encountered it, but I have not tried to fix it. Sorry.
I am also not convinced it is an Adobe issue. Open some of the DNGs in explorer, they should be around 25 megabytes give or take. But I often see them as low as 2 kilobyes, obviously that isn't right so there must be something else along the chain wrong.
Click to expand...
Click to collapse
Ok I don't seem to be having that issue luckily. But as a further test I downloaded a simple Windows conversion utility last night and used it to convert one of the DNG files to JPG and it worked fine. I mean, the colours and general processing were absolute crap, but there was no dark line so whatever problem I'm having certainly doesn't appear to be with the RAW file from the 6P. And as I said, Snapseed edits them without a problem.
After work today I'll post in the Adobe support forums and see if I get any information there.
evo5ive said:
Every one of the RAW images I've taken with this device, regardless of the camera app, produces a dark line on the far right when viewed in Lightroom and Photoshop. Anyone else experience this? I've tried more than one manual camera app with the same result, but it does seem that the Snapseed app can see and edit the DNG on the phone without the green line present. Leads me to believe this is some kind of issue with Adobe so just wondered if anyone else had encountered it. I also tried disabling any import presets but that didn't change anything. Have a look at the attached samples to see what I mean.
Click to expand...
Click to collapse
can upload sample raw file
defcomg said:
can upload sample raw file
Click to expand...
Click to collapse
Sure, try these. Just ran a few more tests and it seems Snapseed is in fact picking up the dark band. BUT, when I shoot either the standard camera app or output to JPG in the manual apps the resulting images do NOT show the dark band. Seems to be a problem that only occurs when the device saves the RAW file.
Uploaded from my PC
Uploaded from phone
evo5ive said:
Sure, try these. Just ran a few more tests and it seems Snapseed is in fact picking up the dark band. BUT, when I shoot either the standard camera app or output to JPG in the manual apps the resulting images do NOT show the dark band. Seems to be a problem that only occurs when the device saves the RAW file.
Uploaded from my PC
Uploaded from phone
Click to expand...
Click to collapse
The Problem is the Active Area DNG Tag the darker area should not be visible somehow Active Area Tag is conflicting with Default crop size tag http://www.barrypearson.co.uk/articles/dng/specification.htm. dcraw based apps seem to use active area tag and ignore the default crop tag so the band is not visible
6P DNG Header
Code:
ExifTool Version Number : 9.69
File Name : ProShot_20151126_143708.dng
Directory : C:/Users/GeorgeKiarie/Downloads
File Size : 24 MB
File Modification Date/Time : 2015:11:26 22:20:33+02:00
File Access Date/Time : 2015:11:26 22:17:54+02:00
File Creation Date/Time : 2015:11:26 22:17:54+02:00
File Permissions : rw-rw-rw-
File Type : DNG
MIME Type : image/x-adobe-dng
Exif Byte Order : Little-endian (Intel, II)
Subfile Type : Full-resolution Image
Image Width : 4080
Image Height : 3028
Bits Per Sample : 16
Compression : Uncompressed
Photometric Interpretation : Color Filter Array
Make : Huawei
Camera Model Name : Nexus 6P
Strip Offsets : (Binary data 25901 bytes, use -b option to extract)
Orientation : Horizontal (normal)
Samples Per Pixel : 1
Rows Per Strip : 1
Strip Byte Counts : (Binary data 15139 bytes, use -b option to extract)
X Resolution : 72
Y Resolution : 72
Planar Configuration : Chunky
Resolution Unit : inches
Software : google/angler/angler:6.0/MDB08L/2343525:user/release-keys
Modify Date : 2015:11:24 01:13:03
XMP Toolkit : Adobe XMP Core 5.6-c011 79.156380, 2014/05/21-23:38:37
Creator Tool : google/angler/angler:6.0/MDB08L/2343525:user/release-keys
Rating : 0
Metadata Date : 2015:11:26 14:46:24-04:00
Date Created : 2015:11:24 01:13:03
Document ID : E76921AC715FABD3C153F15B23AEEA74
Original Document ID : E76921AC715FABD3C153F15B23AEEA74
Instance ID : xmp.iid:42b35b1d-eeff-ea44-a7be-becf042fbc8c
Format : image/dng
Raw File Name : ProShot_20151126_143708.dng
Version : 9.3
Has Settings : False
Has Crop : False
Already Applied : False
Photographic Sensitivity : 100
History Action : saved
History Instance ID : xmp.iid:42b35b1d-eeff-ea44-a7be-becf042fbc8c
History When : 2015:11:26 14:46:24-04:00
History Software Agent : Adobe Photoshop Camera Raw 9.3 (Windows)
History Changed : /metadata
CFA Repeat Pattern Dim : 2 2
CFA Pattern 2 : 0 1 1 2
Exposure Time : 1/110
F Number : 2.0
Exif Version : 0221
Shutter Speed Value : 1/110
Aperture Value : 2.0
GPS Version ID : 2.3.0.0
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Time Stamp : 18:37:11
GPS Date Stamp : 2015:11:26
ISO : 100
Date/Time Original : 2015:11:24 01:13:03
Focal Length : 4.7 mm
TIFF-EP Standard ID : 1 0 0 0
DNG Version : 1.4.0.0
DNG Backward Version : 1.1.0.0
Unique Camera Model : Nexus 6P-Huawei-google
CFA Plane Color : Red,Green,Blue
CFA Layout : Rectangular
Black Level Repeat Dim : 2 2
Black Level : 52 52 52 52
White Level : 1023
Default Scale : 1 1
Default Crop Origin : 8 8
Default Crop Size : 4016 3008
Color Matrix 1 : 0.8125 -0.2265625 -0.125 -0.3203125 1.265625 0.0390625 -0.0390625 0.2265625 0.453125
Color Matrix 2 : 1.0078125 -0.2890625 -0.21875 -0.5625 1.6328125 -0.046875 -0.0703125 0.2109375 0.640625
Camera Calibration 1 : 1 0 0 0 1 0 0 0 0.9921875
Camera Calibration 2 : 1 0 0 0 1 0 0 0 0.9921875
As Shot Neutral : 0.46875 1 0.6328125
Calibration Illuminant 1 : D65
Calibration Illuminant 2 : Standard Light A
Active Area : 2 48 3026 4080
Forward Matrix 1 : 0.578125 0.21875 0.1640625 0.15625 0.84375 0 -0.015625 -0.2890625 1.1328125
Forward Matrix 2 : 0.6875 0.015625 0.265625 0.2109375 0.6796875 0.1015625 0 -0.5390625 1.3671875
Opcode List 2 : (Binary data 3908 bytes, use -b option to extract)
Opcode List 3 : (Binary data 4 bytes, use -b option to extract)
Noise Profile : 0.00020673168 1.8208447e-006 0.00020673168 1.8208447e-006 0.00020673168 1.8208447e-006
Aperture : 2.0
CFA Pattern : [Red,Green][Green,Blue]
GPS Date/Time : 2015:11:26 18:37:11Z
GPS Latitude : 13 deg 4' 13.48" N
GPS Longitude : 59 deg 33' 59.05" W
GPS Position : 13 deg 4' 13.48" N, 59 deg 33' 59.05" W
Image Size : 4080x3028
Shutter Speed : 1/110
Focal Length : 4.7 mm
Light Value : 8.8
Moto Nexus 6 DNG Header
Code:
ExifTool Version Number : 9.69
File Name : paraiso.dng
Directory : C:/Users/GeorgeKiarie/Pictures/DNG/other
File Size : 25 MB
File Modification Date/Time : 2015:08:04 02:07:42+02:00
File Access Date/Time : 2015:08:04 02:04:32+02:00
File Creation Date/Time : 2015:08:04 02:04:32+02:00
File Permissions : rw-rw-rw-
File Type : DNG
MIME Type : image/x-adobe-dng
Exif Byte Order : Little-endian (Intel, II)
Subfile Type : Full-resolution Image
Image Width : 4208
Image Height : 3120
Bits Per Sample : 16
Compression : Uncompressed
Photometric Interpretation : Color Filter Array
Image Description :
Make : motorola
Camera Model Name : Nexus 6
Strip Offsets : (Binary data 26769 bytes, use -b option to extract)
Orientation : Horizontal (normal)
Samples Per Pixel : 1
Rows Per Strip : 1
Strip Byte Counts : (Binary data 15599 bytes, use -b option to extract)
X Resolution : 72
Y Resolution : 72
Planar Configuration : Chunky
Resolution Unit : inches
Software : google/shamu/shamu:5.0/LRX21O/1570415:user/release-keys
Modify Date : 1970:01:22 17:47:12
CFA Repeat Pattern Dim : 2 2
CFA Pattern 2 : 2 1 1 0
Copyright :
Exposure Time : 1/1653
F Number : 2.0
ISO : 40
Date/Time Original : 1970:01:22 17:47:12
Focal Length : 3.8 mm
TIFF-EP Standard ID : 1 0 0 0
DNG Version : 1.4.0.0
DNG Backward Version : 1.1.0.0
Unique Camera Model : Nexus 6-motorola-google
CFA Plane Color : Red,Green,Blue
CFA Layout : Rectangular
Black Level Repeat Dim : 2 2
Black Level : 64 64 64 64
White Level : 1023
Default Scale : 1 1
Default Crop Origin : 8 8
Default Crop Size : 4200 3112
Color Matrix 1 : 0.6953125 -0.0859375 -0.09375 -0.4609375 1.296875 0.1328125 -0.109375 0.2578125 0.5390625
Color Matrix 2 : 1.21875 -0.4296875 -0.25 -0.4609375 1.5 0.015625 -0.046875 0.21875 0.609375
Camera Calibration 1 : 1 0 0 0 1 0 0 0 1
Camera Calibration 2 : 1 0 0 0 1 0 0 0 1
As Shot Neutral : 0.5390625 1 0.6640625
Calibration Illuminant 1 : D65
Calibration Illuminant 2 : Standard Light A
Forward Matrix 1 : 0.7578125 0.0859375 0.1171875 0.2734375 0.828125 -0.1015625 0.015625 -0.28125 1.0859375
Forward Matrix 2 : 0.6328125 0.046875 0.28125 0.1640625 0.7578125 0.078125 -0.046875 -0.640625 1.5078125
Opcode List 2 : (Binary data 3908 bytes, use -b option to extract)
Noise Profile : 0.00051471478 0 0.00051471478 0 0.00051471478 0
Aperture : 2.0
CFA Pattern : [Blue,Green][Green,Red]
Image Size : 4208x3120
Shutter Speed : 1/1653
Focal Length : 3.8 mm
Light Value : 14.0
when opening nexus 6 dng in PS /LR the image res is 4200 x 3112 but on dcraw based apps res is 4208 x 3120 now had moto added Active area tag i believe there would have been a dark area on pixels that go past 4200.
on lightroom pc DNG Recover Edge plugin should make it go away .
it would be interseting to see how the header of a 5x or 6p without that issue looks like
defcomg said:
The Problem is the Active Area DNG Tag the darker area should not be visible somehow Active Area Tag is conflicting with Default crop size tag http://www.barrypearson.co.uk/articles/dng/specification.htm. dcraw based apps seem to use active area tag and ignore the default crop tag so the band is not visible
when opening nexus 6 dng in PS /LR the image res is 4200 x 3112 but on dcraw based apps res is 4208 x 3120 now had moto added Active area tag i believe there would have been a dark area on pixels that go past 4200.
on lightroom pc DNG Recover Edge plugin should make it go away .
it would be interseting to see how the header of a 5x or 6p without that issue looks like
Click to expand...
Click to collapse
Very interesting, thanks for that. I'll look into that plugin for sure. So I'm assuming the problem lies in the RAW tag generated by the phone, and if that's the case it means it could be fixed with a simple software patch, correct? Just trying to get my info straight so I can submit a bug report to Google. (Bit embarrassed to admit that I'm a photographer by profession yet know very little about the technical workings of RAW formats )
evo5ive said:
Very interesting, thanks for that. I'll look into that plugin for sure. So I'm assuming the problem lies in the RAW tag generated by the phone, and if that's the case it means it could be fixed with a simple software patch, correct? Just trying to get my info straight so I can submit a bug report to Google. (Bit embarrassed to admit that I'm a photographer by profession yet know very little about the technical workings of RAW formats )
Click to expand...
Click to collapse
yeah its a simple software issue that can be rectified with a patch
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
moto z
Code:
- Your warranty is now void.
- You have been warned.
- Use at your own risk.
Introduction:
This is the Official Lineage OS 18.1 thread for the moto z.
Downloads:
Please follow the install instructions in your device's Wiki page linked below exactly, and make sure your device's firmware matches the required firmware listed.
griffin - Official builds
griffin - My unofficial with Google Apps/Pixel goodies included. Passes SafetyNet by default. OTA's roll roughly once a month. Support not guaranteed or implied.
If you don't follow these instructions, or use 3rd party add-ons (like Magisk) please don't expect support here.
Known Bugs:
Find any? Report them according to this guide.
Notes:
The only supported GApps package at the moment is MindTheGapps, linked on our Wiki page about gapps.
Kernel Source: https://github.com/LineageOS/android_kernel_motorola_msm8996
To be honest I just forgot to make the thread when builds started lol - enjoy
Thank you so much for your work on this!
I don't know whether this is a problem with the actual ROM or whether it's because my phone is slowly dying, but I sometimes get hangs / crashes and reboots. (Haven't yet managed to get a log of a crash).
I attached some logs of error messages that looked suspicious to me.
The first I get very regularly (every 30 secs roughly).
The moto mod stuff I only saw once or twice.
I also see logs like this a lot (don't know whether that's of any interest). Every time I see those lines it's directly 100 of them spammed in one go. These always appear whenever I'm using my finger swipe to scroll a list view:
Code:
04-23 22:17:59.129 0 0 W : [ 1317.352555,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.129 0 0 W : [ 1317.352577,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
04-23 22:17:59.129 0 0 W : [ 1317.355378,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.129 0 0 W : [ 1317.355394,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
04-23 22:17:59.978 0 0 W : [ 1318.205331,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.978 0 0 W : [ 1318.205352,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
04-23 22:17:59.992 0 0 W : [ 1318.208144,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.992 0 0 W : [ 1318.208162,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
GedeonBlack said:
Thank you so much for your work on this!
I don't know whether this is a problem with the actual ROM or whether it's because my phone is slowly dying, but I sometimes get hangs / crashes and reboots. (Haven't yet managed to get a log of a crash).
I attached some logs of error messages that looked suspicious to me.
The first I get very regularly (every 30 secs roughly).
The moto mod stuff I only saw once or twice.
I also see logs like this a lot (don't know whether that's of any interest). Every time I see those lines it's directly 100 of them spammed in one go. These always appear whenever I'm using my finger swipe to scroll a list view:
Code:
04-23 22:17:59.129 0 0 W : [ 1317.352555,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.129 0 0 W : [ 1317.352577,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
04-23 22:17:59.129 0 0 W : [ 1317.355378,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.129 0 0 W : [ 1317.355394,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
04-23 22:17:59.978 0 0 W : [ 1318.205331,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.978 0 0 W : [ 1318.205352,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
04-23 22:17:59.992 0 0 W : [ 1318.208144,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
04-23 22:17:59.992 0 0 W : [ 1318.208162,0] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
Click to expand...
Click to collapse
I'll look but I've seen dying hardware do similar. I haven't seen these FWIW.
I think I "decrypted" the crashes!
Almost all the time it's the same app (Threema, a messenger). The crashes do not happen suddenly but announce themselves. First it starts to stutter a few times and reacts slower, then it hangs forever.
To debug what's happening, I opened a root console and put in
Code:
dmesg -w > ./test.log
And then I waited until the crash happened again. The last line was particularly interesting. It's from the lowmemory killer and something about swap. Then the phone just hung. The display still works, but it doesn't react to inputs (neither touch nor buttons). The symptoms are exactly identical to how it looks when my Linux desktop runs out of ram when Matlab is doing Matlab things again. (which somehow fits what's in the log...)
From then on whenever I used this app and I noticed the phone to start stuttering, I instantly minimized and killed the app. No crashes since then. Afterwards, I went to the console and drew the dmesg log
Code:
dmesg > ./testN.log
(test2.log and test3.log). In both occasions, I see the lowmemorykiller in the log. So it's not a dying flash like I first assumed. In those logs, you can see the "com.termux" lines to see when I started the terminal.
Has something about the low memory behavior changed?
EDIT: Unfortunately, I somehow can't upload test2.log ... but it's very similar to 3.
Hey, I flashed my old Moto Z with the official LineageOS Build and get sometimes hangs / crashes and reboots.
First the Phone freezes about 10 sec, then it reboots. I tried both official ROMs (April/March) but the Problem happens with both.
Then I took an old MindTheGapps 11.0 arm64 version (got an update of the latest Version when logged into playstore) but no changes.
I installed only 4 additional Apps (Okla Speed Test, Fritz WLAN App, Samsung Internet Browser, VLC) so no Threema.
If you tell me, how to collect logs, let me know.
It seems the former LineageOS 17 Version is no longer available
I finally got the chance to try this ROM as well (actually the LineageOS for microG derivative of it, but it should be close enough for me to post my experiences in this thread, right?). Seems mostly solid so far. Thanks again for creating it!
GedeonBlack said:
I also see logs like this a lot (don't know whether that's of any interest). Every time I see those lines it's directly 100 of them spammed in one go. These always appear whenever I'm using my finger swipe to scroll a list view:
Click to expand...
Click to collapse
npjohnson said:
I'll look but I've seen dying hardware do similar. I haven't seen these FWIW.
Click to expand...
Click to collapse
FWIW, I get these exact log lines as well:
Code:
05-24 18:32:31.578 0 0 W : [12256.587099,2] msm8996-pinctrl 1010000.pinctrl: not freeing pin 6 (GPIO_6) as part of deactivating group gpio6 - it is already used for some other setting
05-24 18:32:31.578 0 0 W : [12256.587149,2] msm8996-pinctrl 1010000.pinctrl: not freeing pin 7 (GPIO_7) as part of deactivating group gpio7 - it is already used for some other setting
That's not only in the situation GedeonBlack described; it looks like about 500 of them get generated per second whenever a finger is touching the screen. They are a bit annoying because they don't seem to have a tagname and thus are difficult to filter out from adb logcat without external tools. They don't seem to be related to any issues, though. I wouldn't describe my device as dying, it generally behaves itself and runs stably. But I have taken it apart a few times and it's plausible that I've damaged something.
The only problem -- albeit a major one -- I currently have with this ROM is related to SIM Tool Kit, which is necessary for Mobile ID to work. In LOS 17, it was working intermittently. The way I could tell was by whether STK is visible in the app drawer: if it's not there, Mobile ID requests would not pop up on the phone. Usually, removing and reinserting the sim card made it work. In this ROM, however, I haven't seen it show up in the app drawer yet, and predictably, Mobile ID requests don't show up either. I'm still looking at the logs, trying to figure out what could be causing the issue. Also, I'm open to suggestions. If STK has any known problems, if there is some workaround I should try, or if I'm barking up the wrong tree, please let me know.