<mentis>
then i dd'ed the uboot at bs=1024 seek=32
lerc_ has joined #arm-netbook
lerc has quit [Ping timeout: 264 seconds]
TheLarch has joined #arm-netbook
TheLarch has joined #arm-netbook
TheLarch has quit [Changing host]
voronaam has quit [Quit: Leaving.]
L84Supper has quit [Ping timeout: 272 seconds]
<Skaag>
ssvb: I just found something interesting. I booted Android on it, and discovered the brightness in Android is reversed
<Skaag>
that is, it is brightest when the slider is all the way to the left
<Skaag>
the more I move it to the right side, it dims, until the backlight is completely off
voronaam has joined #arm-netbook
<libv>
Skaag: *sigh*
<libv>
Skaag: i seem to remember crap like that from the sunxi disp unification
<libv>
i have the exact same hw, but all i did with it so far is take it out of the box and then put it aside, as i am spending my time on lima right now
<libv>
and there is no chance that i will get to boot this device until the 30th or so
<Skaag>
lime is the mali reverse engineering effort to produce an open source version right?
<Skaag>
lima
<Skaag>
damn autocorrect
<libv>
yes
<Skaag>
I suspect this is something to do with brightness
<Skaag>
I inspect the processes, the drivers, etc, it all looks good
<Skaag>
in theory.
<libv>
ok, so fbdev is showing up ok?
<Skaag>
I'm trying to find a way to manually set the brightness via some device in /sys or /proc
<Skaag>
yes, and fbset shows the correct resolution, memory location, etc.
<Skaag>
fbset -i
<Skaag>
funny thing is that this LCD is not even going to be my final device, it is going to be working with a regular VGA monitor, which I am pretty sure will work just fine
lerc has joined #arm-netbook
<Skaag>
But until I get there, I need this to work because it's my R&D platform and I rely on this small LCD with a Touch Screen until the more expensive one arrives towards the end of January...
<Skaag>
and I know the hardware is fine because I boot its built-in android and the screen works fine, the touch screen is great and accurate
<mentis>
what is eGON.BT0 ?
lerc_ has quit [Ping timeout: 255 seconds]
<libv>
Skaag: DISP_CMD_LCD_SET_BRIGHTNESS
<libv>
in include/video/sunxi_disp_ioctl.h
<libv>
hack the vga enabling code which can be found somewhere
<libv>
it's a mess, i know, but lima is much higher priority for me now
<libv>
i can barely believe that it will soon be two months since i did a quick once over over this code
<Skaag>
this one: DISP_CMD_LAYER_SET_BRIGHT = 0x5b, /* brightness */ ?
lundman has left #arm-netbook [#arm-netbook]
<Skaag>
the lima stuff must be exhausting
<Skaag>
why are you doing it? :-)
<libv>
Skaag: that's the messed up and horribly broken ioctl number which violates everything, yes
<Skaag>
LOL
<libv>
Skaag: you can find this in the drivers/video/sunxi/disp/ code
gsilvis has quit [Read error: Connection reset by peer]
<libv>
and see how it is hooked up
gsilvis has joined #arm-netbook
<libv>
Skaag: look at the header file, near the top of the ioctl definitions
tinti has joined #arm-netbook
<Skaag>
I'm grepping the entire tree for DISP_CMD_LAYER_SET_BRIGHT ;-)
<libv>
/* fail when the value is 0x02 in linux,why??? */
<libv>
why? because someone did not RTFM on ioctls :)
<libv>
as i said
<libv>
drivers/video/sunxi/disp/
<Skaag>
drivers/video/sunxi/disp/dev_disp.c
<libv>
i think it might just be an int being passed through, or worse, a char or so
<mentis>
is eGON.BT0 important when booting from sdcard?
<libv>
it's a horrible mess, so you could just copy a few ideas from it
<Skaag>
:-)
<libv>
all you need it to do is set your brightness
<libv>
basically open /dev/disp, ioctl argv[1], exit
<Skaag>
let's see if I can get that to work
<Skaag>
hopefully that's all it is. a reversed default brightness issue.
<libv>
wait and see :)
<libv>
Skaag: if it is, then the fex name seems to be "lcd_pwm_pol"
<libv>
yeah, the code backs it up
<libv>
lcd_pwm_pol
<Skaag>
thanks for that
<Skaag>
right now it's set to 0
<Skaag>
what do you think…? :-)
<libv>
nothing?
L84Supper has joined #arm-netbook
<Skaag>
ha :)
<libv>
...
TheLarch has quit [Ping timeout: 272 seconds]
<libv>
the pwm code is one of those nasty bits where, for no currently apparent hw reason, they seem to have completely rewritten the logic
<Skaag>
ok I managed to get it to compile, not to see how to target armhf platform with gcc
<libv>
ah, no, i am talking out of my ...
<Skaag>
s/not/now/g
<ibot>
Skaag meant: ok I managed to get it to compile, now to see how to target armhf platform with gcc
<Skaag>
lol :)
<libv>
Skaag: compile it on the device
<Skaag>
right, good idea
<ssvb>
yeah, if you want to have a good nap :)
<Skaag>
ok the display blinked
<libv>
ssvb: for a 20 line max c file?
<libv>
my mele and a7hd are quite happy compiling my limare code
<ssvb>
libv: ah, it's not the kernel
<libv>
i did end up forgoing autoconf though.
<libv>
that was quite glacial, but that was more to do with nfs over wifi
<ssvb>
I have a cortex-a15 based chromebook sharing nfs root with my mele
<ssvb>
so I'm offloading some of the compilation work to it
<Skaag>
I tried setting the brightness to 10, the return code is -1
<Skaag>
I'm guessing that's a failure
<libv>
yes
<libv>
anything in dmesg?
<Skaag>
nothing important
<Skaag>
just this: disp: process 1979 (disp_util) has skipped the version handshake
<Skaag>
I'm going to check what values that function accepts
<libv>
Skaag: unsigned int
<Skaag>
but what ranges are valid...?
<Skaag>
I see it's a __u32
<libv>
Skaag: nothing in the actual code behind it that could return -1
<libv>
the error is from the ioctl handler
<libv>
top level
<Skaag>
:-(
<Skaag>
ah, it takes two values: BSP_disp_lcd_set_bright(__u32 sel, __u32 bright);
<libv>
oh, right on
<mentis>
guys, there is a tool - mksunxiboot in u-boot-sunxi/tools; it is supposed to crate sun4i bootable image, what do i pass as input file? spl.bin? uboot.bin? sth else?
<libv>
this sel stuff, this really must go, but so should this whole disp ioctl interface tbh
<libv>
sysfs and debugfs make this crap so much easier to deal with from userspace
<Skaag>
argh I'm getting rusty
<Skaag>
I'm trying to add send_cmd() an optional extra argument by adding unsigned long extval = 0x00 but am getting errors
<Skaag>
I guess this is C, not C++
<libv>
it ends in .c
<Skaag>
no optional parameters in C? I forgot already.
<libv>
there's ways to avoid that :p
<Skaag>
never mind I'll do this differently
<libv>
which mainly means to claim all the time that c++ is magic :p
<libv>
after a while, people stop asking you about c++ code, and you never do crazy things in c code anymore :p
<libv>
oh, as a consequence, you might need to change your job description and/or your job though :p
<libv>
nothing important
<Skaag>
:-)
lerc has quit [Read error: Operation timed out]
<Skaag>
I sent it in args[2] and set it to 0x20
<Skaag>
I tried 5 also, not working
<libv>
try 0xFFFFFFFF
<libv>
there is no range checking on this thing
<libv>
so who knows what the real range is
<Skaag>
argh...
<libv>
ah, 0-256 might be a sane range
hp__ has joined #arm-netbook
voronaam has quit [Quit: Leaving.]
<Skaag>
still 01
<Skaag>
-1
<Skaag>
I'm basically checking if cmd == DISP_CMD_LAYER_SET_BRIGHT and if yes, I set args[2] to 0x7f
<Skaag>
I also printf() something to make sure that point in the code is reached
<libv>
give me a minute... typing up some fresh c code now
<Skaag>
thanks
<libv>
(i should be attaching tying textures to samplers properly in lima, but hey...)
<mnemoc>
E/HAL ( 1023): Cannot load library: link_image[1916]: 1023 could not load needed library 'libCedarX.so' for 'camera.exDroid.so' (load_library[1118]: Library 'libCedarX.so' not found)
Quarx has quit []
mentis has quit [Ping timeout: 246 seconds]
mentis_ has joined #arm-netbook
popolon has quit [Quit: Quitte]
<mentis_>
where can i find libCedarX.so ?
mentis_ has quit [Read error: Connection reset by peer]
mentis_ has joined #arm-netbook
tinti has joined #arm-netbook
drachensun has quit [Quit: Leaving]
drachensun has joined #arm-netbook
eebrah has quit [Ping timeout: 250 seconds]
mentis_ has quit [Quit: Konversation terminated!]
eebrah has joined #arm-netbook
arokux has joined #arm-netbook
ibrah has joined #arm-netbook
eebrah has quit [Ping timeout: 252 seconds]
ibrah is now known as eebrah
eebrah is now known as Guest64227
Guest64227 is now known as ibrah
Jef91 has joined #arm-netbook
servili007 has joined #arm-netbook
merbanan has quit [Ping timeout: 246 seconds]
<servili007>
hno, could you bring my pull request in sunxi-boards to amery's attention?
<jinzo>
mnemoc, ^^
<jinzo>
servili007, mnemoc == amery
<servili007>
ah, good to know, thank you
<servili007>
Also, anyone willing to test some CM10 work that has an mk802ii, let me know
<jinzo>
uh, you're fighting the noble battle - how's it going?
<servili007>
fine actually, lol, my source building setup isn't wonderful, but I've got working builds
<jinzo>
sounds good
<techn_>
servili007: seems that you have different mk802ii than the other
<servili007>
techn_, based on?
<techn_>
in you .fex there seems to be addional/different parameters
<servili007>
the additions are from the most recent 10-29 rikomagic release
<techn_>
[boot_disp], ie
<servili007>
right
<techn_>
also could you check with a10-meminfo which one is right density
<techn_>
2048/4096
<servili007>
according to the other user, they did, and it does show 4096. I was taking their word for it, but since I had one disassembled and my memory was reporting right, I didn't bother
ibrah has quit [Read error: Connection reset by peer]
<mnemoc>
servili007: making a .fex based on a different device is... risky
<servili007>
mnemoc: I took quite a few precautions and thoroughly tested both devices, I'm quite confident in it
<mnemoc>
servili007: why didn't you start from the script.bin in nanda?
<servili007>
I did
<mnemoc>
your commit says it's based on the uhost
<servili007>
right, I started at the mk802ii, then used the uhost and mele and a few others to figure out details
<servili007>
since, honestly, the stock script seemed to be a mess of guess work and copy-pastes
<servili007>
most mk802ii users have started to flash uhost updates to solve problems because of the better builds on that front
<servili007>
plus I own one as well, so I already had some work and experience on it
<servili007>
I still have one more commit to make before I'd like it pulled, I can change the density based on what meminfo reports
<techn_>
servili007: if that is same device with mk802-ii.. I'd like to see your commit top mk802-ii and then file renamed to correct
<mnemoc>
+1
<servili007>
techn_: The device is the same. I had started working on that script before the pull request for the misnamed one was created, so it floated under my radar without me saying anything
<mnemoc>
servili007: git rebase is very friendly
<mnemoc>
make a rename
<servili007>
mnemoc: okay okay, fair enough :P
<servili007>
I'll have it up within a few hours
<mnemoc>
one commit to rename the .fex to the name you like, another commit making the changes you want
<mnemoc>
drachensun: considering those drivers include all the knowledge we have, fixing them sounds like a good idea ;-)
<mnemoc>
and maybe in the process find out what is it about :p
<drachensun>
lol
<drachensun>
yeah I guess so
<drachensun>
I've locked at them before, they used some kind of kernel lock that changed and they didn't update to the new lock style correctly
<drachensun>
s/locked/looked/
<ibot>
drachensun meant: I've looked at them before, they used some kind of kernel lock that changed and they didn't update to the new lock style correctly