rz2k has quit [Read error: Connection reset by peer]
iamfrankenstein has quit [Ping timeout: 245 seconds]
hp__ has joined #imx6-dongle
hste has quit [Ping timeout: 240 seconds]
newbie has joined #imx6-dongle
newbie is now known as Guest65007
hp__ has quit [Ping timeout: 264 seconds]
newbie1 has joined #imx6-dongle
Guest65007 has quit [Ping timeout: 264 seconds]
hste has joined #imx6-dongle
newbie1 has quit [Ping timeout: 264 seconds]
fossxplorer has joined #imx6-dongle
hste has quit [Ping timeout: 240 seconds]
datagutt_ has quit [Remote host closed the connection]
<projectgus>
are there known circumstances under which modeswitching causes total kernel lockups?
<projectgus>
i seem to be getting them on mode switches and also sometimes on resume from display sleep
<projectgus>
but i'm connected to my tv with bad EDID so that might be some of it
<projectgus>
have a DVI<->HDMI adapter in the post so I can try it on a different display
<abrasive>
i've never had that.
<projectgus>
fair enough
<projectgus>
there's a couple other environmental things that might be blame
<projectgus>
if it still happens afterwards I'll redirect the console to serial and see if it panics
<abrasive>
the only (and consistent) lockups i had were when running cpufreq with vendor uboot
<abrasive>
but of course that does not apply to you.
datagutt has joined #imx6-dongle
<projectgus>
wow, this default debian wheezy install hasn't installed the normal kernel module blacklist files
<projectgus>
meaning evbug is loaded and reporting every keypress in dmesg... whee!
<projectgus>
weird
<abrasive>
does debian try and load every available module on boot?
<projectgus>
no but I think evbug will load when evdev loads if it's not already blacklisted
<projectgus>
at least on my other systems here there's a blacklist.conf installed by a system package that just contains evbug and some other things you don't usually want
<projectgus>
it looks like wheezy has migrated that package to a different package
<projectgus>
so it could be a wheezy problem, more likely something weird with this setup I think
<projectgus>
because they would have noticed it
<projectgus>
hmm ok maybe kernel isn't locking
<projectgus>
gdm just fails to start and gets stuck in a restart loop
<projectgus>
meaning init never starts my serial console
<projectgus>
making it look like it's locked (no video output, no serial console)
<projectgus>
probably the weirdest thing now is xrandr can only see one mode, 640x480
<projectgus>
even though the hdmi driver code appears to set a fairly decent list of default modes if/when EDID fails
<abrasive>
the fallback is pretty bad.
<projectgus>
if I'm reading the code right, it looks really comprehensive
<projectgus>
lots of modes listed in mxc_cea_mode, plus xga and sxga
<projectgus>
this may be where my lack of knowledge of linux graphics becomes a factor
<projectgus>
if I look in /sys/class/graphics/fb0/modes then I see all the modes
<projectgus>
if I look in xrandr I only see vga
datagutt_ has joined #imx6-dongle
rz2k has joined #imx6-dongle
datagutt has quit [Remote host closed the connection]
datagutt_ is now known as datagutt
<projectgus>
ok, so Xorg is using FBDEV and fbdev is (can?) only read the current mode when it starts up
<projectgus>
which explains why I only have my boot console mode,
<abrasive>
oh, that explains some things.
<projectgus>
abrasive: should i have a different X driver installed/loading?
<projectgus>
sorry I have pretty much nfi when it comes to linux graphics stuff
<abrasive>
there's a vivante one but it depends on closed binaries
<projectgus>
ah, and that's what the ubuntu image uses?
<projectgus>
ok, that makes sense then
<projectgus>
i was only actually doing X support as a nice to have to round out the installer, my own use case is totally headless
<projectgus>
so this might be where I stop yak shaving and get back to what I was actually planning to do with the gk802
<projectgus>
at least for now
<abrasive>
i won't bug you about investigating i2c then ;)
<projectgus>
well, I do have a second one coming and I'm vaguely interested in running xbmc
<projectgus>
so you never know
<abrasive>
mmm, i want xbmc up too.
<projectgus>
but it looks like the path of least resistance there is to run ubuntu, using their hwpacks and binary blob ickiness
<abrasive>
have burned way much time already though
<abrasive>
yeah
<abrasive>
or yocto
<projectgus>
so will probably go that way too
<abrasive>
yocto's less bloaty
<abrasive>
but not yet mature for us.
<projectgus>
right, so they provide a binary hwpack type thing to match yocto's library versions, etc? or something like that?
<abrasive>
that's... the idea
<projectgus>
ok
<abrasive>
nobody has hardfp libs yet, so i can't run arch with gpu accel
<projectgus>
ah, right
<abrasive>
stupid closed source grumble grumble
<projectgus>
by arch you mean Arch Linux?
<abrasive>
yes.
<abrasive>
it's my daily drive
<abrasive>
my original plan for my gk802 was as a tiny silent desktop
<projectgus>
gotcha
<projectgus>
bed time for me, thanks for filling in the gaps in my understanding
* abrasive
mumbles and waves hands vaguely yet enthusiastically