Vasco has quit [Read error: Connection reset by peer]
afaerber has joined #linux-exynos
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-exynos
dlezcano has quit [Ping timeout: 260 seconds]
aballier has quit [Quit: leaving]
aballier has joined #linux-exynos
Vasco has joined #linux-exynos
Vasco has quit [Max SendQ exceeded]
Vasco has joined #linux-exynos
Vasco has quit [Max SendQ exceeded]
Vasco has joined #linux-exynos
isaque has joined #linux-exynos
dlezcano has joined #linux-exynos
krzk has quit [Quit: Ex-Chat]
wiewo has quit [Ping timeout: 260 seconds]
dlezcano has quit [Ping timeout: 260 seconds]
wiewo has joined #linux-exynos
dlezcano has joined #linux-exynos
wiewo_ has joined #linux-exynos
LiquidAcid has joined #linux-exynos
wiewo has quit [Ping timeout: 260 seconds]
leming has quit [Ping timeout: 264 seconds]
leming has joined #linux-exynos
decay has quit [Ping timeout: 250 seconds]
prahal has joined #linux-exynos
dlan has quit [Ping timeout: 276 seconds]
decay has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
prahal has quit [Quit: prahal]
prahal has joined #linux-exynos
paulk-aldrin has joined #linux-exynos
prahal has quit [Ping timeout: 244 seconds]
isaque has quit [Quit: isaque]
isaque has joined #linux-exynos
<Wizzup>
javier__: Do you recall why the brightness in mainline kernel is much more coarse than the chromeos kernels om peach-pi?
<Wizzup>
Now it runs from 0-7, IIRC it used to run from 0 to 100
<javier__>
Wizzup: I haven't looked why that happens
<javier__>
but IIRC this is a regression because it used to be brighter in older kernels
<javier__>
(unless I'm misremembering)
<Wizzup>
You can get to the brightest mode, but there are less steps 'in between'
<Wizzup>
So for example, I'm sitting outside in the semi dark now, and I can't jump to the convenient setting. ;-)
paulk-collins has joined #linux-exynos
<javier__>
Wizzup: s/regression/change actually since it doesn't really matter that much the initial brightest level
<javier__>
Wizzup: yeah, I also can't try an older kernel now since I'm in the middle of a task
<javier__>
isaque: sorry, I missed your message yesterday
<javier__>
isaque: did you mean that you want to use the kernel image in a Fedora package (instead of building your own?)
paulk-aldrin has quit [Remote host closed the connection]
<Wizzup>
javier__: I understand, I thought that maybe it was just a different/default algorithm
prahal has joined #linux-exynos
<isaque>
javier__: np my friend ;)
<javier__>
Wizzup: I don't know what changed the default tbh, but I also notice that is less bright now
<javier__>
isaque: vmlinuz is just either a bzImage or zImage AFAIK
<isaque>
javier__: yeah, exactly that, but I'm not sure if that's possible - I'm reading a lot of stuff :)
<javier__>
both are supported by the bootz u-boot command
<javier__>
isaque: it depends wether Fedora packages an Exynos kernel
<javier__>
or more likely, a multi-platform kernel that has Exynos SoC support and DTBs for the Snow
<javier__>
I dunno the state of the multi-platform distro packages since for ARM I always build my own kernels
<javier__>
s/packages/kernel packages
<isaque>
javier__: dtb is there in /boot/dtb-kernelversion
<isaque>
javier__: and I've checked .config so, I suppose it does
<javier__>
isaque: cool
<isaque>
javier__: but I can't make it boot, using signed or uboot, always fails me (well uboot fails me using whatever kernel version)
<isaque>
javier__: btw, I'm running signed 4.5.2 kernel, but I noticed I don't have sound
<javier__>
isaque: yeah, sound is a very long standing issue
<javier__>
I've tried to fix it a few times but it doesn't seem to be trivial
<isaque>
javier__: I saw in your comments that, so my question is do you knwo which version has it?
<isaque>
javier__: just chromeos or any older kernel does it too?
<javier__>
isaque: just ChromeOS, it never worked on mainline
<isaque>
javier__: really? oh boy!
<Wizzup>
javier__: if you have the machine, you can check with /sys/devices/platform/backlight/backlight/backlight/{max_,}brightness
<isaque>
javier__: last question and I promise you I won't bother you anymore :) I saw your link for mali drivers, but the instructions to build it is too old (2012) and based on Ubuntu. Do you know of anything more recent?
<javier__>
Wizzup: I don't have access to the machine right now (or rather, I do but I don't have space on my desk for it right now :) )
<javier__>
isaque: not really, the only place I know is the ARM developers site that provides the blobs and kernel out-of-tree module
<javier__>
and that is circa 2012 yeah
<javier__>
isaque: but there shouldn't be too many changes there, only that the kernel module may no apply cleanly on current mainline but forward porting shouldn't be that hard
<isaque>
javier__: I see, I never mess with kernel, so I don't know how hard is that. I mean, I compile kernels, but never had to deal with patches and stuff.
<LiquidAcid>
javier__, actually it's not very pretty :(
<Wizzup>
javier__: ack, my max is 7
<isaque>
javier__: I'll probably get back to chromeos to be able to use sound and then I'll try mali
<javier__>
isaque: if you use the ChromeOS then you already have mali
<javier__>
*the ChromeOS tree
<javier__>
LiquidAcid: what's not pretty? the ARM site?
<isaque>
javier__: oh... interesting... I'll give it a try then
<javier__>
isaque: you just need the user-space bits
<LiquidAcid>
javier__, integrating the mali codebase into a current kernel
<javier__>
LiquidAcid: oh, I see. I have never tried so I (wrongly) thought it wouldn't be too much work
<isaque>
javier__: there's always a catch then
<javier__>
isaque: yes, but that shouldn't be too hard (famous last words as LiquidAcid just pointed me out)
<LiquidAcid>
javier__, well, once you have it, you can easily move it forward with each kernel release
<javier__>
LiquidAcid: I see, I meant to isaque that just integrating the user-space bits should be easier than having to also rebase the out-of-tree module and integrate it
<LiquidAcid>
javier__, userspace is just putting the blob somewhere, isn't it?
<javier__>
LiquidAcid: I believe so, and probably using a DDX that plays nicely
<LiquidAcid>
oh yeah, that as well
<LiquidAcid>
or just use good ol' fbdev
<javier__>
nod
<LiquidAcid>
which probably doesn't work anymore on current kernels
<LiquidAcid>
or at least it only works in single buffer mode
<javier__>
LiquidAcid: I also wonder how well the Exynos DRM fbdev emulation works
<LiquidAcid>
javier__, iirc it depends on the blob, some require another ioctl to export the fbdev backing buffer as dmabuf
<javier__>
LiquidAcid: I see
<LiquidAcid>
here on the exynos4412 based odroids it just uses MEM_{MAP,UNMAP}_EXT
<javier__>
isaque: if your goal is to have the best user experience but use a generic linux distro instead of the ChromeOS rootfs, then I would probably just use crouton or something similar
<javier__>
isaque: dunno if that has Fedora support though
<javier__>
LiquidAcid: I should get an exynos4412 board
<LiquidAcid>
javier__, good luck ;)
afaerber has joined #linux-exynos
<Wizzup>
LiquidAcid: modesetting works fine as ddx
<Wizzup>
I believe fbdev still works
<Wizzup>
Not sure if it works with mali, though
<javier__>
LiquidAcid: LOL
<LiquidAcid>
Wizzup, no, you need at least armsoc for mali to work
<Wizzup>
ack
<LiquidAcid>
Wizzup, and i avoid fbdev since it's running on an emulation layer as javier__ pointed out
<LiquidAcid>
so no vsynced page flips, and everything
<Wizzup>
hmhm
<Wizzup>
I really liked fbturbo for its speed, but it's fbdev with addons
<Wizzup>
so RandR etc also doesn't work well - really happy that works well with modesetting
<LiquidAcid>
Wizzup, does randr work at all with fbdev?
<LiquidAcid>
afaik the fbdev emulation setup is static, so you can't change res on the fly
<Wizzup>
LiquidAcid: I don't think so, no, that is my point wrt fbturbo
<isaque>
javier__: crouton... humm, well, that might be my last resource... I'll try the other options first...