TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-exynos
isaque has quit [Quit: isaque]
amitk has joined #linux-exynos
masta has joined #linux-exynos
krzk has joined #linux-exynos
paulk-collins has quit [Quit: Leaving]
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...
<isaque> javier__, LiquidAcid, Wizzup, thanks guys
<LiquidAcid> Wizzup, i've been working on a G2D EXA implementation: https://github.com/tobiasjakobi/xf86-video-armsoc
<LiquidAcid> maybe that improves performance for you?
<javier__> isaque: Ive dual boot on my Chromebook, I use latest mainline for hacking on Exynos but have ChromeoOS for normal usage
<isaque> javier__: ChromeOS kernel or full ChromeOS?
<javier__> isaque: ChromeOS kernel + ChromeOS rootfs
<Wizzup> LiquidAcid: ah, that may be nice to try!
<Wizzup> Interesting that you chose to use armsoc
<Wizzup> It was quite unstable for me all the times I tried it, but I could try it again
<LiquidAcid> Wizzup, what else would you choose as basis?
<Wizzup> well, it depends on if you want mali, I guess
<LiquidAcid> Wizzup, even if you don't want mali
<Wizzup> As I said, the modesetting ddx works well for me, except for 2d speed
<LiquidAcid> Wizzup, modesetting doesn't provide the necessary infrastructure to plugin the g2d exa code
<LiquidAcid> Wizzup, same goes for fbdev
<Wizzup> Yeah, I figured as much
<Wizzup> I just recall that I would make armsoc crash just by loading a png in firefox at the time
<LiquidAcid> so actually i didn't have much choice there
<Wizzup> I will attemp to try your g2d code somewhat soon and see how it works
<javier__> LiquidAcid, Wizzup: probably a dumb question from a complete ignorant about gfx
<LiquidAcid> Wizzup, beware that you need both kernel and libdrm patches for it
<javier__> but why there are so much fragmentation for DDX drivers?
<Wizzup> javier__: well, modesetting ddx is attempting to solve that, essentially
<Wizzup> This may be a better question for libv, perhaps :)
<LiquidAcid> javier__, i think the reason basically is that no company feels responsible for writing a ddx
<LiquidAcid> javier__, you don't have amd or intel behind it
prahal_ has joined #linux-exynos
<javier__> LiquidAcid: I see
prahal has quit [Ping timeout: 252 seconds]
prahal_ has quit [Quit: prahal_]
<LiquidAcid> is it just me, or is patchwork for samsung-soc broken?
<LiquidAcid> the webinterface only ever shows the first few submitted patches, then there is a big gap, then come 2015 patches
amitk has quit [Quit: leaving]
prahal has joined #linux-exynos
prahal is now known as prahal_
paulk-collins has quit [Quit: Leaving]
isaque has quit [Quit: isaque]
prahal_ has quit [Quit: prahal_]
<javier__> LiquidAcid: yeah, it seems something is borked there
nashpa has quit [Quit: Going away]
nashpa has joined #linux-exynos