00:03 <mmind00> I don't think so ... it's all pretty much debian standard

01:42 <steev> amstan: speaking of... when using your rotation script, when i rotate the screen 90 degrees (? portrait instead of landscape when in "tablet mode") the screen just goes black instead of rotating... is this... expected or should i be looking for something in xorg's logs and such

01:43 <amstan> steev: works for me

01:43 <amstan> does xrandr --left work?

01:43 <steev> what version of modesetting driver do you use

01:43 <amstan> whatever's in arch

01:43 <steev> mother of god

01:43 <steev> that's as useful as latest

01:44 <steev> leming: what version of modesetting is in arch?

01:46 <amstan> xf86-video-fbdev 0.4.4-4

01:46 <steev> xf86-video-modesetting

01:46 <amstan> steev: no? wrong thing? lol

01:46 <amstan> i don't have that installed though

01:46 <steev> erm, wtf

01:47 <steev> fbdev doesn't do modesetting

01:47 <steev> it's two separate drivers

01:47 <amstan> ok... but my xrandr works :)

01:47 <steev> ugh

01:48 <steev> hm, debian claims 0.4.4-1

01:50 <steev> and i don't see anything special about -3 to -4, just an abi bump

01:51 <leming> modesetting is built in xorg now, iirc

01:51 <steev> we're still on xorg 1.16

01:51 <steev> so must be a 1.17 thing

01:51 <steev> ah well

01:51 <leming> maybe you should use a distro with software from this century ;)

01:51 <amstan> i can't reproduce rperier's success with running X as root

01:52 <steev> leming: pfft

01:52 <steev> how's that wifi treating you again?

01:52 <leming> working good now

01:52 <steev> finally fixed?

01:52 <leming> i just had to slow things down

01:52 <steev> heh

01:53 <steev> teh arm, it is too fast

03:09 <steev> anyone using mmind00's kernel on a veyron device? i'm curious about the existence of a file

09:05 <mmind00> steev: me :-D ... what file are you looking for?

18:18 <cristian_c> hi, I'd like to solve two issues with rk3188

18:31 <cristian_c> 1) I'd like to enable bt properly in ap6210

18:32 <cristian_c> I've found some strange behaviours, if I type rfkill list, I can see ap6210 bt interface in the output. I can block/unblock the software switch. Some months ago, I tried the patchram plus method but it's difficult to say why it doesn't work. So, I'd like to know if there is a method to set it properly either how I can collect useful info from commands/files. Any ideas?

18:32 <cristian_c> 2) I'd like to access to mount user readable/writable nand partition (i.e. /sdcard)

18:33 <cristian_c> I think loop* block files are related to mtd partitions and I think I could mount /system or /sdcard , mtdblock8 and mtdblock9, respectively (they are ext4 the first one and vfat the second one). So, I'd like to know if maybe I've to enable some CONFIG options in the kernel configuration file or to something else. Any ideas?

18:33 <paulk-collins> hi there

18:33 <paulk-collins> anyone played around with the Asus C201 yet?

18:34 <paulk-collins> also, I have questions about the SoC

19:02 <steev> mmind00: i was curious if /proc/device-tree/compatible exists

19:03 <mmind00> steev: yep seems to exist

19:04 <steev> mmind00: you check if /sys/firmeware/devicetree/base/compatible exists which doesn't exist on cros kernels, but /proc/device-tree/compatible does

19:05 <steev> if you couldn't tell, i'm the one who opened the issues, and your second one has a good point

19:05 <steev> response*

19:05 <mmind00> steev: so I guess it moved to /sys from /proc in the meantime and I guess the /proc/ stuff stays for compatibility

19:05 <mmind00> steev: yep I saw that ;-)

19:07 <mmind00> steev: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-ofw brings enlightenment ... /proc/device-tree is the actual path to use it seems

19:08 <steev> mmind00: ah, okay, i'll do a pullreq shortly then

19:08 <mmind00> ok, great :-)

19:09 <steev> i was thinking it was the other way around, that /sys was the place to look and cros had an option turned off

19:12 <steev> where shortly means, as soon as i get caught up on my emails and pop that sdcard back into my minnie

19:17 <mmind00> yea, but thankfully it is documented how this is supposed to be used ;-)

19:17 <mmind00> I need to finish v2 of the rk3368 clock tree too

19:44 <cristian_c> anyway, some questions about rk3066

20:00 <cristian_c> I get many error messages similar to the following:

20:00 <cristian_c> i2c i2c-3: No ack, Maybe slave(addr: 0x30) not exist or abnormal power-on, retry 2...

20:02 <cristian_c> I've enabled i2c debug options and now I see many many many debug messages in my log

20:03 <cristian_c> similar to the following

20:03 <cristian_c> [ 5.656469] i2c i2c-1: master_xfer[1] R, addr=0x2d, len=1

20:04 <cristian_c> [ 5.658736] i2c i2c-1: master_xfer[0] W, addr=0x2d, len=2

20:04 <cristian_c> Any ideas about how to solve i2c issues?

20:42 <steev> mmind00: awesome, that fixes that. i've got a peach over here maybe i'll look into adding the exynos support based on it. i just need to look through the chromium stuff, i'm pretty sure all the exynos line uses the same mali drivers

20:45 <mmind00> steev: great ... yep I'm also quite sure that these drivers are the same ... exynos is a mali t6xx-something or so if I remember correctly

20:46 <steev> mmind00: well if/when i get armsoc working, can test for sure, running into the same thing amstan was, where it claims it can't find a working configuration for the screen

20:46 <steev> but it's fairly low on my todo list

20:47 <mmind00> yea, thats still puzzling me, as I've updated my Debian to the latest xorg in testing (1.17) and I just needed to recompile the armsoc part to make it work again

20:48 <steev> i'm still using 1.16 (based off jessie here), but i know amstan is using 1.17

20:48 <mmind00> I updated when amstan reported the issues on arch's 1.17, just to see if it is also present on debian

20:49 <mmind00> btw do you have an opinion on the libGL issue ... it gets currently just diverted away ... alternatives are symlinking to mesa-libGL or depending on glshim

20:49 <amstan> mmind00: i'll try it with your kernel sometime next week

20:49 <mmind00> [which is enough for extremetuxracer at least ;-) ]

20:49 <steev> amstan: hah, discovered the thing

20:49 <steev> http://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting/commit/?id=91571cce03adc58a10b5d76307629efc7c994c3e

20:50 <amstan> steev: yeah, but that's in modesetting, weren't we both using fbdev?

20:50 <steev> mmind00: i'd dep on glshim

20:50 <steev> amstan: no... but yes... but no - your xorg has modesetting built in, i have to have the driver

20:50 <amstan> heh

20:51 <steev> that said, i can probably look through the xorg stuff and port it back to the driver

20:52 <cristian_c> amstan' any ideas about race conditions?

20:52 <amstan> cristian_c: i'm sorry if i gave you the impression that i know what your issue is

20:52 <amstan> i was just talking in general

20:53 <steev> amstan: which version of 1.17 are you on?

20:54 <amstan> looks like 1.17.2-2

20:54 <amstan> seems to be an upstream package too, comes from the main arch, not modified for ar

20:54 <amstan> arm*

20:58 <steev> yeah, i was just figuring to look at the debian package and see what they are doing since mmind00 says it works for him

20:59 <steev> i'm planning on bumping my local box to the xorg 1.17 stuff, but it's going to be a huge pita to build it all

21:09 <steev> and is kinda also why it's low on the list