lurchi__ has quit [Quit: Konversation terminated!]
<wens>
jernej: notifiers yes
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 246 seconds]
juri_ has joined #linux-sunxi
tllim has quit [Ping timeout: 276 seconds]
JohnDoe_71Rus has joined #linux-sunxi
selfbg has joined #linux-sunxi
chewitt has joined #linux-sunxi
<jernej>
megi: will you submit your H6 DRAM fix?
airwind has joined #linux-sunxi
pmpp has quit [Disconnected by services]
pmpp_ has joined #linux-sunxi
reinforce has joined #linux-sunxi
ldevulder__ has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 248 seconds]
xes has quit [Ping timeout: 245 seconds]
reinforce has quit [Quit: Leaving.]
xes has joined #linux-sunxi
reinforce has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
matthias_bgg has quit [Ping timeout: 245 seconds]
[7] has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
Putti has joined #linux-sunxi
SopaXorzTaker has joined #linux-sunxi
mzki has quit [Ping timeout: 246 seconds]
mzki has joined #linux-sunxi
warpme_ has joined #linux-sunxi
warpme_ has quit [Client Quit]
matthias_bgg has joined #linux-sunxi
kaspter has quit [Ping timeout: 245 seconds]
yann has quit [Ping timeout: 244 seconds]
ldevulder__ has quit [Quit: Leaving]
dddddd has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 258 seconds]
matthias_bgg has joined #linux-sunxi
tnovotny has joined #linux-sunxi
diego_r has joined #linux-sunxi
AneoX has joined #linux-sunxi
ldevulder has joined #linux-sunxi
warpme_ has joined #linux-sunxi
book` has quit [Quit: Leaving]
book` has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
yann has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
tnovotny has quit [Ping timeout: 268 seconds]
Mangy_Dog has joined #linux-sunxi
tnovotny has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 245 seconds]
freemangordon has quit [Ping timeout: 268 seconds]
<fALSO>
if megi's H6 DRAM fix fixes the "not booting" problems
<fALSO>
he should submit it yes!!!
swiftgeek has quit [Ping timeout: 248 seconds]
swiftgeek has joined #linux-sunxi
megi has joined #linux-sunxi
afaerber has quit [Remote host closed the connection]
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
afaerber has joined #linux-sunxi
<fALSO>
Sirs
<fALSO>
today im gonna try to build the latest uboot on my PC2
<fALSO>
as it is also a ARM64 and uses ATF
<fALSO>
just to figure out if its something from general-uboot or is just for the H6
<fALSO>
as i cant build uboot with debug
<fALSO>
ahhh,, gonna try to figure out if its possible to enable debug just for the SPL part of u-boot
<fALSO>
as that is what seems to fail
warpme_ has quit [Quit: warpme_]
gaston_ has joined #linux-sunxi
warpme_ has joined #linux-sunxi
sunshavi has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
<libv>
v4l2 is amazingly clunky
<fALSO>
yoo libv good day
<libv>
how on earth can you call yourself video infrastructure while treating packed and planar formats totally different
<libv>
unions to deal with the actual format description difference, and then _separate_ ioctls depending on whether you are using planar or packed formats, or both
<megi>
fALSO: to debug u-boot, I usually have to add #define DEBUG at the top of particular files I suspect may be useful. SPL has size limit and just enabling DEBUG globally adds too much debug strings to the code, breaking the limit
<libv>
those who ended up doing randr1.2 and kms were shortsighted and technologically challenged...
matthias_bgg has quit [Read error: Connection reset by peer]
<fALSO>
yes, thats what happened
<libv>
but this format thing is just braindead
<fALSO>
i figured out that theres an #u-boot channel
<fALSO>
i went there now asking for help on how to debug the SPL part of uboot :-O)
<fALSO>
;-)
matthias_bgg has joined #linux-sunxi
<megi>
fALSO: maybe add #define DEBUG at the top of spl_mmc.c
<fALSO>
megi, im gonna see if it builds in a few minutes
<fALSO>
but im at work now, no way to test :(
<fALSO>
just later
airwind has quit [Quit: airwind]
<megi>
fALSO: I tried v2019.07, and after adding CONFIG_SPL_TEXT_BASE=0x20060 it boots fine
<libv>
*sigh*
<libv>
which is what i pointed out at the very start
<megi>
libv: I know :)
<mru>
never trust the defconfig
<libv>
i wonder how many people have run into that
<libv>
such a badly thought out change
<megi>
especially if I copied it myself from prev version :)
<megi>
that's just a cost of not mainlining my changes
<libv>
no, not in this case
<libv>
CONFIG_SPL_TEXT_BASE was a braindead idea
<libv>
the fact that every _board_ defconfig had to be told something _SoC_ specific should've shown people just how bad it was
<libv>
and all of this to give soc_fpga some flexibility
<mru>
send a patch
<libv>
"let's change all defconfigs to account for all the flexibility of fpgas"
<libv>
mru: it was backed out already
<megi>
that was quick
<libv>
at least, afaik, i think someone posted that to this channel after i had run into it
<libv>
yeah well, trini pretty much went it alone
<libv>
he either was under time pressure, or got pressured by the insistence and the age of the merge request
<megi>
it was moved to Kconfig in 9340d8fe8bebf24441f15529b1a32d062158c65f
<libv>
making it soc specific, and overrideable, removing the need to have it in _every_ _board_ defconfig
<megi>
much nicer
<libv>
two massive red flags ignored, lots of pain everywhere
<libv>
v4l2 also forces driver writers to do full, duplicate, buffer management, and to serialize fd accesses
<fALSO>
im also building it with DEBUG=1
<megi>
yeah, I've seen your boot log, it stops where the ATF debug output would normally start
<fALSO>
but it gives no extra info
<libv>
now i understand that some devices might need that
<fALSO>
thats why im gonna try some debug on the SPL part of uboot
<fALSO>
see if i can get further
<fALSO>
or any moar info
<fALSO>
;-)
<libv>
but they should hook their callbacks into the infrastructure at a higher livel
<libv>
and this should not be forced on trivial 12register devices like, for instance, the allwinner csi engiens
warpme_ has quit [Quit: warpme_]
warpme_ has joined #linux-sunxi
<wens>
the m2m apis seem to have some helpers
<wens>
not so much for the standard capture or output types
<libv>
well, all this buffer handling and serialization is something that is quite error prone and hard to debug, and now every driver has their own different version of it, leading to more errors
<libv>
and leading to a massive boost in loc for the worst possible reasons
<libv>
and then this image format thing... when i see a union i already balk... It's an image format, it's not rocket science, and yes, planar versus packed adds difficulty, but this is just useless.
<libv>
anyway, rant over, for now ;p
popolon has joined #linux-sunxi
<wens>
ugh, you're referring to struct v4l2_format?
<libv>
amongst others
<libv>
the format handlers are also split up
vagrantc has joined #linux-sunxi
<libv>
for no good reason
<wens>
the callbacks are split, but it's actually the same ioctl to userspace
<wens>
god knows why you need to split the callbacks :/
<libv>
and to then still pass the unioned top level struct...
<wens>
presumably to let people use the same callback for both in/out lol
<wens>
I spent the last few days trying to get bcm2835_codec to do both splane and mplane, then found out buffer queue management is fixed to one type per direction :/
<libv>
hw restriction, or just driver side vb2 buffer handling?
<wens>
driver (or rather, helper) side
tnovotny has quit [Quit: Leaving]
warpme_ has quit [Quit: warpme_]
freemangordon has joined #linux-sunxi
<libv>
so videobuf2?
selfbg has quit [Remote host closed the connection]
<wens>
yeah
<wens>
v4l2_m2m to be exact, expects 2 buffers, one src, one dst
<wens>
I figure it's not worth the effort to figure out how to get it to take more buffer queues, or be able to switch between splane and mplane types
SopaXorzTaker has quit [Remote host closed the connection]
<libv>
hrm, and you need to mmap each plane separately?
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<wens>
no I don't
<wens>
chromium only supports the mplane api; I'm not about to try and make it support both either :/
reinforce has quit [Quit: Leaving.]
<wens>
the mplane api lets you have different buffers for each plane for the *M types
<wens>
* pixformats
<wens>
you could choose not to support those though
<fALSO>
megi, u-boot built OK with that DEBUG on the spl_mmc
<fALSO>
when i get home ill try it out =)
<fALSO>
lets see if it shows anything moar
<megi>
for me it just show one extra line in the happy case when it works
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
<jernej>
wens, libv: v4l api will get a new version, where a lot of strange things like MPLANE vs. SPLANE should be fixed
<jernej>
I think bbrezillon works on this, among others
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 246 seconds]
<z3ntu>
Hi, has anybody tried PCM/I2S on the A64?
<jernej>
I'm using A64 I2S, but only for HDMI audio
<vagrantc>
works on pinebook with linux 5.2 (maybe earlier)
* vagrantc
has only tested speakers .... but should test headphone too
<z3ntu>
I mean the thing described by the i2s0 devicetree node
tllim has joined #linux-sunxi
<z3ntu>
Normal audio works fine for me too but I can't get the pcm connection between the A64 and a modem connected to the i2s bus working
<anarsoul>
codekipper: ^^
<z3ntu>
anarsoul: Already pinged him when we last wrote but he didn't respond yet
<anarsoul>
z3ntu: are you trying with CPU as master or modem as master?
<anarsoul>
maybe only one or the other works
<z3ntu>
I've definitely configured the modem as slave
<z3ntu>
I'm not sure how to tell the cpu to be master or slave honestly
<megi>
there are two regulators and during reboot only one is left on
<megi>
and it messes up phy initialization for some people
<megi>
on first poweron of the board, both are off
<megi>
and those regs need to be enabled at the same time
reinforce has joined #linux-sunxi
<jernej>
did you check how they deal with that in BSP?
<megi>
otherwise phy chip doesn't respond
<megi>
they probably initialize axp regulators in u-boot
<megi>
for H6 mainline u-boot doesn't touch AXP as it doesn't have support for AXP806/5
<megi>
it's probably only solvable by disabling both regulators during boot in u-boot
<megi>
I have a quick hack to power them off in the kernel before reboot, just for testing
<megi>
but I lack testers
<megi>
:)
<jernej>
why can't you just power cycle both regulators in Linux?
<megi>
it's not that
<megi>
easy
<megi>
I would probably have to make them exclusive
<fALSO>
well, i dont want to budge into the conversation
<megi>
because multyiple devices may be using the same regulator in theory
<fALSO>
but on the H6 after a *reboot* seems that something isnt disabled
<megi>
so I can't just do regulator_disable/regulator_enable from the driver
<fALSO>
that the kernel after boots again goes to panic
<megi>
it's all reference counted
<fALSO>
maybe its something related ;-)
<megi>
it would be nice to have support in u-boot for AXP806, so that it can use ethernet on Opi3
<megi>
and it would fix this issue too
<fALSO>
hum isnt that the same as the opi one plus ?
<fALSO>
i have ethernet
<fALSO>
ahh you mean ethernet in uboot
<megi>
I think that's the only proper solution for this issue, atm
<jernej>
so back to the original question, patches can go in now? we can deal with this problem later, or in U-Boot :)
<megi>
yes
<jernej>
btw, default syscon value should be changed to 0x58000, right?
<jernej>
but that patch is already applied
<megi>
I'm just thinking of adding support for two phy regulators to stmmac-sun8i glue code, so that I can get rid of incorrect HW description in DTS
<z3ntu>
anarsoul: Any idea what mclk-fs value I have to use?
<megi>
jernej: that 8 is then stripped by the other patch anyway
diego_r has quit [Ping timeout: 258 seconds]
<megi>
change to 58000 just avoids warning during boot
<jernej>
yes, but driver will complain in dmesg
warpme_ has quit [Quit: warpme_]
diego_r has joined #linux-sunxi
<z3ntu>
The docs say PCM_SYNC is 8kHz and I've configured the modem to use a 2048kHz clock/PCM_CLK, so I did 2048/8 = 256 and used that
<jernej>
frankly, I'm not sure why default value even matter
<megi>
yeah
<jernej>
fALSO: I think you're pretty unlucky regarding H6 (re)boots. My H6 boards are pretty stable, so maybe configuration issue?
<fALSO>
yes
<megi>
some of those other bits disable internal EPHY
<wens>
jernej: honestly the default value shouldn't matter
<fALSO>
i wish there was a "repo" with working kernel configs ;-)
<fALSO>
mine are somewhat hit and run
<wens>
(and the kernel reporting a difference is annoying as well)
<jernej>
but there must be a reason why montjoie introduced that
warpme_ has joined #linux-sunxi
<wens>
debug use?
<megi>
probably
<jernej>
true, but that could be reported with appropriate debug print functions
<jernej>
s/true/probably/
<megi>
I have some work in progress mess, to add support for AXP805/H6 to u-boot
<jernej>
well, there is a thing that last few bits supposedly represent calibration value
<megi>
but it's outside of DM, and inside the maze of ifdefs that I'm not sure is acceptable anymore
<megi>
all those bits are docummented in H6 manual
pmpp_ is now known as pmp-p
msimpson has quit [Remote host closed the connection]
msimpson has joined #linux-sunxi
diego_r has quit [Ping timeout: 258 seconds]
diego_r has joined #linux-sunxi
<megi>
btw, poweroff on linux is a bit weird on these SBCs.. it basically leaves devices as is, and just halts the CPU it seems... I guess it's a complicated problem
<megi>
seems like Linux assumes the power will be cut off after shutdown by some external force :)
<wens>
megi: if the platform hooks the powerdown callback (such as the AXP driver does), that is called last, otherwise it halts (busy loop style)
<megi>
maybe AXP805 has some reset register/command that can be used by linux to intialize regulators to the initial power on state...
<wens>
reset?
<megi>
hmm seems like AXP805 has some bits in REG 32 to power down/reset PMIC
warpme_ has quit [Quit: warpme_]
<libv>
heh, a start offset into a single buffer, this is how i know yuv buffers
Mangy_Dog has quit [Disconnected by services]
Mangy_Dog has joined #linux-sunxi
<megi>
ah found it, and the powerdow seems to work... I was just confused because USB phy led is still on even after powerdown
<megi>
but the board starts again after short press of POK
<megi>
USB hub, not phy
sunilmohan has quit [Ping timeout: 246 seconds]
<montjoie>
jernej: wens: if the value is not the default, it is sign of a bootloader which forgot to disable things
sunilmohan has joined #linux-sunxi
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
<wens>
montjoie: sure, but that's not helpful to the user in any way
<wens>
should probably be a debug message
<wens>
otherwise it's just noise and misleading for novice users trying to figure out why their board doesn't work
<montjoie>
I will send a patch if you want
matthias_bgg has quit [Ping timeout: 245 seconds]
<montjoie>
unrelated, on my nanopineoplus2, how to know if MACPWR="PD6" is the right choice ? the DT have gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>;
vagrantc has joined #linux-sunxi
<aalm>
3==D, i guess
<montjoie>
yeah I think that, but since network dont work, something is bad
tuxillo has quit [Remote host closed the connection]
afaerber has quit [Quit: Leaving]
msimpson has quit [Read error: Connection reset by peer]
msimpson_ has joined #linux-sunxi
msimpson has joined #linux-sunxi
msimpson_ has quit [Remote host closed the connection]
<codekipper>
z3ntu: Hi, what are you trying to do?
<z3ntu>
codekipper: Hi, I have an A64 board with a modem connected to it and the audio is connected with the i2s0 lines; and I can't get it to work :)
<fALSO>
nice
<codekipper>
what code base are you using?....I think something is broken on linux-next
<codekipper>
is there any i2c control for the modem?
<z3ntu>
So modem works fine (it's a Quectel EC25), most stuff is connected via USB but for the audio it's via pcm/i2s. I have a minimal modem codec driver (pretty much like gtm601.c) and I have added a simple-audio-card node in the dts which should connect the i2s0 node with the ec25 node (provided by the "modem codec driver" mentioned above)
<mru>
AT commands, more likely
<z3ntu>
codekipper: 5.1-rc7, the configuration of the modem happens via AT commands
<codekipper>
well it seems to probe ok...but that barf doesn't look healthy
<mru>
modems usually use the 3gpp/etsi standard commands + a few additions of their own
<codekipper>
can you probe the pins?...any chance of getting a logic analyser on there
<z3ntu>
I have a multimeter and the board has some test points, but I can't do much more than that
<fALSO>
i've used a esp8266
<fALSO>
to add WIFI to a eletronics project
<fALSO>
it also talked serial, with AT commands
<fALSO>
but instead of phone numbers
<codekipper>
mmmm....even a cheap usb analyser can be useful.
<fALSO>
it was to connect to wifi ;-)
<mru>
any logic analyser is better than none at all
<fALSO>
i bought a FAKE SALAE something
<fALSO>
from china
<fALSO>
even works with the original software :-)
<codekipper>
one thing is that I can't see where i2s0_pins are defined
<z3ntu>
codekipper: In the same dts file
<z3ntu>
line 313
<codekipper>
OK....I was looking deeper
<z3ntu>
I could probably add it to the a64.dtsi file and send it upstream and it should be applicable to all a64 boards (but so far at least none upstream use i2s0)
<codekipper>
any chance of getting the register settings during and after playback
<z3ntu>
that's with the busybox devmem util, right?
<libv>
meh, for packed formats, you just queue/dequeue indexes (not even more opaque 'handles') from v4l2
<libv>
for planar... you need to go all out and provide the mappings...
<libv>
pfff
<libv>
appalling stuff
mlt- has joined #linux-sunxi
<libv>
hrm, no, wrong, but still not working... digging
<megi>
fALSO: official u-boot repo is on git.denx.de
<megi>
hmm, they moved to gitlab?
<mru>
denx has had a gitlab server for years
<mru>
they finally got rid of the old gitweb
<megi>
ah
<mlt->
uhm... for those out of the loop. What options do I have with Mali on A64? Lima is not there yet, and binaries are for older kernel only?
lsjet has quit [Quit: Leaving]
SopaXorzTaker has quit [Remote host closed the connection]
warpme_ has quit [Quit: warpme_]
<libv>
ah, pebcak
diego_r has joined #linux-sunxi
<jernej>
mlt-: binaries are independent of kernel version. However you might have problems compiling appropriate kernel driver, because it needs to be fixed with almost every new kernel release.
<jernej>
but it's perfectly doable, I'm using binaries with 5.2.
<jernej>
as part of LibreELEC
reinforce has quit [Quit: Leaving.]
<mlt->
jernej: I'm just somewhat overwhelmed with so many names and flavors. I have Pine64 with Mali 400/utgard and I am running aarch64 with 4.20 kernel. So I need to have necessary records in devicetree, have DRM driver, binary blobs, and then X11 driver?
<mlt->
I see something "meson" in the repo, but it does not ring a bell
<mlt->
is it a name for driver version?
<anarsoul>
mlt-: blob provides only GLES and it's somewhat useless for desktop linux
<mlt->
hey! I guess I'm using your repo!
netlynx has quit [Quit: Ex-Chat]
<mlt->
Why is it useless? I just recently tried to start using X and it seems a bit slow on Pine64.
<mlt->
You mean it is only GL specific acceleration? no simple 2D composition or something?
<fALSO>
yap
<fALSO>
scrolling in apps is very slow etc
iamfrankenstein has quit [Quit: iamfrankenstein]
<mlt->
So is it just the best as it gets with running e.g. Firefox on Pine64? Nothing to improve?
<fALSO>
i've somewhat managed to play a video inside x with vlc almost perfectly ;-D
<anarsoul>
mlt-: desktop linux wants desktop GL
<fALSO>
with the CEDRUS driver :-)
<anarsoul>
mali blob doesn't have it
<mlt->
here! cedrus... I saw that name before, but still I don't know where it fits :-)
<mlt->
is it GL that is not GLES?
<mlt->
So does it all sums up into no Yourube in Firefox on Pine64?
<anarsoul>
GL is desktop GL
<fALSO>
cedrus i think is the HW video codec decoder
<anarsoul>
GLES is GLES
<fALSO>
like h265 and h264 etc
<libv>
cedarx is the name the hw has
<anarsoul>
mlt-: you may have better luck with chromium without any hw accel
<mlt->
like utgard... cedrus?
<anarsoul>
anyway, no browsers on linux use hw acceleration to decode video
<fALSO>
its like the vdpau... of nvidias
<fALSO>
sort of ;-)
<mlt->
I'll give chromium a try
<anarsoul>
well, no popular browsers
<libv>
cedrus is the name of the REed driver, by the like of nove, jemk, and rellla
<anarsoul>
IIRC gnome web can use vaapi for decoding
<anarsoul>
neither chromium or firefox can
<fALSO>
i can run firefox.. but its quite slow
<fALSO>
and not for videos
<fALSO>
but for browsing is ok
<mlt->
I see constant cursor flicker in FF
<fALSO>
usable if youre in a emergency ;-D
<mlt->
I thought that maybe some better driver will do it
<fALSO>
i dont know how is the DESKTOP support on raspberry pis
<libv>
mlt-: cursor either is drawn by software, or is a hw overlay
<fALSO>
but i guess is the same
<anarsoul>
mlt-: enable ShadowFb for xf86-video-modesetting to get rid of flickering
<libv>
the latter makes it part of drm-kms
<libv>
which, incidentally, took 6-7years to support different cursor formats.
<libv>
einmal mit profis arbeiten.
<jernej>
there is no specific HW cursor plane on DE2 and DE3
ldevulder has quit [Quit: Leaving]
<jernej>
A64 has DE2
<libv>
not specific, no
<libv>
but iirc, on the original display engine, the sprite makes for a perfect cursor
* libv
digs out the a64 user manual
<mlt->
Isn't ShadowFb is On by default? I saw some man off the web
<jernej>
there is no details about DE2 in A64 manual
<jernej>
take DE2 manual from wiki
<mlt->
I'll give it a try once I get to it
<anarsoul>
mlt-: IIRC it's not
<mlt->
It just seems that overall experience with X on Pine64 is slower than on RPi 2 :/
<mlt->
anarsoul: I'll give it a try... I just have ssh only at the moment
<mlt->
thanks!
<anarsoul>
well, rpi uses vc4 which exposes desktop GL
<libv>
jernej: why not use one of the ui overlays for the cursor?
<anarsoul>
libv: no one implemented it
<libv>
*rolls eyes*
<fALSO>
;-D
<libv>
it's the most trivial optimization
<anarsoul>
having hw cursor would definitely help a bit
<jernej>
why sacrificing whole overlay just for cursor?
<libv>
jernej: yes
<libv>
better than doing that in software, and then dealing with damage and stuff
<anarsoul>
jernej: it's not used anyway, so I don't see why not to
<libv>
if the cursor is off, you have an extra overlay to play with
<jernej>
you have to know that second DE2 mixer
<jernej>
has only 1 VI and 1 UI
<libv>
better than no cursor
<jernej>
and UI is automatically primarly plane
<libv>
and as said, when the cursor is off, you can have the plane, atomic should be able to rule either out
<libv>
err, both
<libv>
the cursor as a plane is a no-brainer choice
<jernej>
well, anyone can send patch for that, if he/she want to change anything and we can discuss implications then
<jernej>
my use cases don't need cursor
<libv>
the thing is, jbarnes was forced to deal with overlays when wayland was proven to be useless powerwise compared to android hwcomposer
<libv>
and jbarnes never cared about anything display
<libv>
his kms planes proposal was pretty useless
<libv>
no z ordering
<libv>
no per plane pageflip notifications
<libv>
he also failed to realize that the main fb is the lowest order "plane" and that the cursor is a special restricted plane (often size, colourspace, and usually on top)
<libv>
if you take that logical step, you can automatically start abusing any plane for a cursor as needed
<jernej>
so you suggesting that X11 driver could also use overlay plane for cursor (not only that marked as cursor plane)? That certainly true
<libv>
well, iirc, that's how androids hwcomposer does it
<libv>
but my memory might be skewed, it's been 7ys since i worked on that
<libv>
shortly before this channel was founded, incidentally
<jernej>
ok and I don't use desktop on ARM, so I never really researched this topic
<mlt->
What are my chances with DirectFB on Pine64 (for freerdp)? I built/installed aur/directfb , but dfbinfo freezes my Pine64. I yet have to connect serial console to see if there is something helpful. Is it supposed to work on Mali 400 / to be faster than through X ?
<libv>
directfb?
<mlt->
yes
<libv>
in this decade?
<mlt->
what are my alternatives?
<mlt->
:-)
<anarsoul>
mlt-: directfb is pretty much dead
<mlt->
ok.. good to know, you saved me some time
<mlt->
I just saw some posts about having that + freerdp on RPi
<mlt->
I thought to give a thin desktop a try on Pine64
<libv>
mlt-: write the sunxi-drm support for using an overlay as a cursor, and your issue should be gone
<anarsoul>
it won't speed up browsers a lot :)
<jernej>
yeah, vanilla browsers are notoriously slow on ARM
<libv>
it will keep X from drawing the cursor manually, and then garbaging the old area
ldevulder has joined #linux-sunxi
<mlt->
I'm just trying to find at least some use for the board :-) I thought to use it as IR blaster with simple circuit, but it lacks usable PWM on GPIO.... now no fast X, no fast freerdp... I'd better have it for PiHole and other simple networking...and use RPi for the rest :-)
<libv>
this is the thing right, you not only draw the cursor on the new location on screen, the application needs to go redraw the old overwritten pixels for you
<libv>
this is why having a software cursor is such a pain, and sacrificing an overlay for it is a good thing
<jernej>
isn't this already done in with x11 modesetting driver? just a guess
<libv>
it makes sense for android devices to not specifically support the cursor case, and instead make that hw a generic full size non-scaled argb overlay
<libv>
jernej: with no cursor support claimed by the kms driver?
<jernej>
yeah, overlay should do it
<jernej>
make it 16x16 in size
<libv>
i doubt that anyone has gone there
<libv>
64x64 usually
<jernej>
ok, but the point still stands
<mlt->
I'm surprised it is not a thing... I think I saw a video with mripard and I presumed it is pretty much default these days... no one draws cursors by hand
<jernej>
DRM planes support was implemented by me for DE2 and DE3, but as I said, I don't care for desktop
<libv>
jernej: as said, jbarnes did not take the next logical steps with kms planes, as he did not care and he had fulfilled his role as an architect at intel
<libv>
and... the xf86-video-modesetting driver probably never encountered hw without an actual cursor
<anarsoul>
well, I'm not interested in hacking xf86-video-modesetting
<jernej>
one issue is that as soon as plane is marked as an cursor plane, all software will assume it has extremly limited capabilities
<libv>
jernej: i am the bitter divorced father of modesetting btw. i trailblazed structured display driver development on via hw, and no-one really cared for any of it. When a guy from intel wanted to know more, i got shot down by keithp. Keithp then got hired by intel and f-ed it up with randr1.2, and randr1.2 got badly maimed into a kernel style header file called kms
<anarsoul>
jernej: it's possible to go the other way - modesetting can use any available plane if no planes are marked as cursor
<libv>
if i had not been blackballed at intel, i would've joined my nokia team to intel, and i and the only display guy i rank better than myself, would've made atomic something useful, and we would not have allowed jesse to get away with the planes nonsense
<jernej>
anarsoul: exactly my point
<jernej>
libv: you mean planes concept wouldn't exist at all?
<libv>
err, no, ville and i were the only two guys who had done any overlay work in the decade previous
<jernej>
anyway, they're very useful for full screen video playback :) (my use case)
<libv>
we would've included z-ordering from the start, and per plane flipping, and we have the mental capacity to meld the main fb and cursor in the fold as well
<libv>
especially since we had low power arm experience at the time
<libv>
the plane stuff was presented at xdc2011, and i was preoccupied with the telechips tablet in my backpack, on the other end of a usb-cable
<jernej>
but that exist now with atomic kms, right?
<libv>
if i had not been blackballed, i would've been at intel for 3-4months already then
<libv>
z-ordering, yes
<libv>
per plane fb flipping notification, no
<libv>
ville was moved to bug fixing and got sidetracked, so his atomic property ideas got sidetracked as well
<libv>
and it took many years for it to go anywhere
<anarsoul>
I took a brief look into the code and it doesn't look trivial to implement
mlt- has quit [Quit: got to go]
<libv>
jernej: you have to remember the time...
<libv>
nobody cared for overlays in the second half of the 2000s
<libv>
as everyone claimed that 3d engines could do all that
<libv>
and, yes, they can
<libv>
at considerable cost, both setup, power and time
<jernej>
anarsoul: I think that's the reason wayland took off :D
<libv>
did it? really?
<libv>
it's only 11y old now
<libv>
and intel dropped it back in... 2013 or early 2014
<libv>
and krh moved on to google in the meantime
<libv>
and remember, jbarnes was tasked with introducing planes to get the power draw down to comparable levels of android with their hwcomposer
<jernej>
in 2000's I was using BIOS int10h to change display mode :D
<libv>
jernej: it was a time when people claimed that it was impossible to get away from that
<libv>
and then i came around and saw the via code with its register tables dumped from the bios by via people themselves
<libv>
and noticed structure.
diego_r has quit [Ping timeout: 245 seconds]
<libv>
the term modesetting is 15y old somewhere next month, and is quite the misnomer, but it sidestepped the confusion with XDisplay