<liquidAcid>
i tried to rebase them onto 3.16-rc1 but ran into some trouble: dropped patch 1 (not needed anymore i guess) and had to modify patch 2 a bit
<tfiga>
2 of 4 patches are not needed anymore due to other changes and one is a fix that I intend to send for next rc
<tfiga>
"ARM: EXYNOS: Fix core ID used by platsmp and hotplug code" is the fix
<tfiga>
but I guess it needs to be rebased on top of all the changes that went in for 3.16
<libv>
where you wonder how this code ever got accepted.
<libv>
with such little testing
<tfiga>
libv: I'm afraid you are blaming wrong code
<ssvb>
libv: well, it's all about policy, forbidding handling of the physical addresses in the userland may be inconvenient, but it also prevents bad practices
<libv>
ssvb: sure, but a lot of fbdev is bad practices
<libv>
tfiga: nope, but i am happy that this code no longer is being used today
<tfiga>
first of all, the fbdev over HDMI using videobuf2 was just a hack in one of vendor trees
<libv>
this is two fixes in videobuf2-fb.c which iirc, was upstream
<libv>
it never was tested at 32bpp
<libv>
and the author believed that one should never use smem_start
<libv>
but smem_start comes with the territory, whether it is a good practice or not
<tfiga>
what do you need physical addresses for?
<libv>
mali.
<tfiga>
we've been using ARM Mali blobs with Exynos DRM without any need for such hacks
<libv>
tfiga: recently, yes.
<libv>
this fixes are a year old now
<libv>
these even
<tfiga>
uhm, right, this is odroid-3.0.y branch
<tfiga>
the ugly vendor tree I mentioned few lines above
<liquidAcid>
:D
<ssvb>
tfiga: is exynos using (or going to use) drm/kms for android?
<tfiga>
ssvb: hard to say
<tfiga>
android products tend to use vendor kernels
<tfiga>
does it really matter, though?
<ssvb>
of course it does, android is by far the most widely used linux distribution
<tfiga>
you can run android on whatever you want, just provide any necessary adaptation layer
<ssvb>
no, it's *you*, who has to provide the necessary adaptation ;)
<tfiga>
if I remember correctly, I used to play with Android running on top of Exynos DRM
<tfiga>
but that was completely unrelated to production software
<tfiga>
just my private work to do some testing
<tfiga>
no, I don't think we have
<tfiga>
Samsung provides all the adaptation layer for whatever they prefer, e.g. fbdev
<ssvb>
in any case, if drm/kms is not suitable for use in production (yet), then why should anyone care about drm/kms?
<tfiga>
I'm not sure whether it is really less ready than those hacks in vendor kernels
<tfiga>
this is mostly a matter of policies
<tfiga>
Chromium project does use DRM
<ssvb>
fbdev is the lowest common denominator, it has a stable api/abi (well, except for this 'smem_start' issue) and it works everywhere
<tfiga>
fbdev is going to die
<tfiga>
well, it's already dying
<liquidAcid>
the sooner, the better
<libv>
but it is not dead yet
<libv>
and it will take a long while for it to die as well
<tfiga>
well, things can't be just removed from the kernel
<tfiga>
but it is considered seriously deprecated already
<libv>
people have been considering that for a decade already
<tfiga>
by the way, isn't KMS API stable as well?
<libv>
tfiga: not really
<libv>
tfiga: and it's pretty halfarsed as well
<libv>
atomic will get closer though
<libv>
finally.
<tfiga>
I'm not really talking about GEM, which requires device-specific IOCTLs to create them
<tfiga>
but mode setting is rather generic
<libv>
i think cursor size was finally introduced
<tfiga>
does fbdev support cursor?
<libv>
no, it isn't as generic as keithp and anholt initially claimed it was
<libv>
kms finally introduced cursor sizing
<ssvb>
tfiga: but the android vendors still somehow see fbdev as an easier and less risky solution for their products?
<tfiga>
if you use basic mode setting, at the same level of functionality as provided by fbdev I don't think you would have any stability issues
<libv>
tfiga: up to a point
<tfiga>
ssvb: because there is no need for people to change their habits?
<libv>
tfiga: kms plane support was an unfinished thought
<ssvb>
tfiga: the point is, I can't use basic modesetting with a random android kernel today
<tfiga>
and get rid of all the bad practices
<tfiga>
which takes time and so money
<ssvb>
who has to do this freaking job?
<libv>
tfiga: planes should've been a primary object from the start, and the direct attachment of an fb to a crtc should've been disallowed
<tfiga>
ssvb: why do you want to use an android kernel?
<libv>
in future, this is where things will go
<libv>
so no, even basic things are not going to be stable
<tfiga>
android kernel is made for android
<tfiga>
for the factory android provided with the hardware
<ssvb>
tfiga: first of all, it is made for the hardware
<ssvb>
tfiga: if you can offer a better kernel for any random android device, then I would be surely interested in it
<tfiga>
well, it is, but it is also so severely hacked up to make the hacky userspace run on it that it won't run with any clean userspace
<libv>
vendors also still do not always comply with the gpl
<libv>
and if they do, you get an android kernel if you are lucky
<tfiga>
it all depends on what you really want to achieve
<tfiga>
ssvb: for Exynos based devices you can already get most of the features on mainline...
<libv>
_today_
<libv>
i have been doing lima for more than 3 years
<tfiga>
no, not today, most of the multimedia stuff have been there since many years
* WarheadsSE
facedesk
<tfiga>
G2D, MFC, FIMC
<libv>
getting mali based hardware with kernel code, that first happened 2 years ago
<libv>
for very select hardware
<libv>
you still do not get it for most of the mali based devices out there
<libv>
if you want to do anything else than only hack the kernel, vendor trees are a firm reality
<tfiga>
what do you mean by anything else?
<libv>
...
<tfiga>
running a clean Linux distro on Android device?
<libv>
lima is all userspace
<libv>
i would be insane to go rewrite the mali kernel driver for the purpose of rewriting the kernel driver
<libv>
that's just busywork
<tfiga>
with the need to have a number of hack for _every_ found device, because _every_ device has a different set of quirks in its vendor kernel?
<libv>
yup, and a few fixes for the biggest fuckups in the vendor code
<libv>
tfiga: what other option is there?
<ssvb>
tfiga: that's a good point, I'm actually seriously considering to implement a validation test program for fbdev
<libv>
tfiga: would you really want to spend most of your time comparing the changes to the mali kernel drivers on the vendor kernels matching new mali userspace binaries?
<tfiga>
libv: you still haven't answered to my question, what do you want to achieve?
<libv>
so that you can go fix your completely rewritten driver
<libv>
tfiga: a mesa driver that is a drop in replacement for the binary
<tfiga>
so you want compatibility with Android
<tfiga>
more specifically with the same stock Android that comes with the hardware
<libv>
tfiga: with actual users, not just the 5 brave souls who have dared to jump through the 2000 hoops, and actually succeeded
<libv>
tfiga: it is not that insanely difficult from my experience so far
<liquidAcid>
libv, what chance does such a mesa driver even have for upstream inclusion?
<libv>
liquidAcid: none
<tfiga>
so I'm not sure what's the problem
<libv>
liquidAcid: as i do not want it included
<libv>
liquidAcid: feel free to listen to my fosdem talk
<liquidAcid>
actually i did
<libv>
then you must remember that bit
<liquidAcid>
my point is: no upstreaming = short to no lifecycle at all
<libv>
liquidAcid: no upstreaming == multiple mesa version it can build and run against
<tfiga>
right now, most people won't even care whether they have a blob driver or a mesa driver
<tfiga>
they just buy an android-based phone
<tfiga>
or tablet
<libv>
indeed
<tfiga>
setting up a mesa driver on such phone will be 1999 hoops for them
<libv>
then there is a 0.1% who actually try something interesting
<libv>
of those, very few will get very far
<libv>
so throwing in even more hurdles should be avoided
<tfiga>
so why not to do something clean?
<libv>
and if they have managed to get that far
<liquidAcid>
libv, i don't see how this should work properly
<libv>
would you want them to rebuild their kernel every 5 minutes?
<tfiga>
hmm?
<libv>
would you want them to fully rebuild mesa every 5 minutes, just because you fixed a handful of bugs in your driver?
<tfiga>
how does this depend on whether vendor hacks are used or not?
<tfiga>
and well, you can provide patches
<libv>
i try to work around the vendor hacks, so that there is no absolute need to change the kernel
<tfiga>
not source code patches
<tfiga>
you can do incremental updates of the software
<libv>
barely anyone does that on the pc
<libv>
as it tends to break more than fix
<libv>
now on mobile hw...
<tfiga>
hmm, except the company behind the biggest OS on the desktop PC marget
<tfiga>
market*
<libv>
yes, with a massive QA department
<libv>
and hardware especially brought up to work with this OS
<libv>
and while making absolutely sure that none of the driver infrastructure is changed
<tfiga>
maybe that's right
<libv>
in our world, the driver infrastructure constantly changes
<tfiga>
but working around vendor hacks and making a mesa driver just to make a mesa driver
<tfiga>
depending on how bad the vendor hacks are, can be
<tfiga>
for example you won't get a secure system with operating on physical addresses in userspace
<libv>
i have been exposed to very few vendor hacks so far
<libv>
yet that is how the mali driver was designed
<tfiga>
is it?
<libv>
yes, why else would i need smem_start?
<tfiga>
I'm not sure
<libv>
i am, of course, using the same memory allocator and mapper as the binary
<tfiga>
is this about current version?
<libv>
no
<libv>
not the absolute very latest of this quarter, no
<tfiga>
and this is what I mean
<libv>
...
<libv>
tfiga: how many vendor kernel currently do this properly?
<libv>
tfiga: and from how many vendors?
<tfiga>
I don't know exactly, but I don't suppose many do
<libv>
tfiga: would you have preferred me to wait with doing any arm gpu freeing
<libv>
until all the vendors provide exactly all the infrastructure i should be requiring?
<tfiga>
you can make your own infrastructure
<libv>
or would you rather have me spend all of my time fixing up all the vendor kernels of all the devices out there
<libv>
for ever and ever?
<tfiga>
of course you can bootstrap most of the work on vendor's one
<libv>
like a hamster in a wheel?
<libv>
bootstrap?
<libv>
i am still on mali-400
<tfiga>
see freedreno
<libv>
i have only just started mali-t series
<tfiga>
started on Qualcomm's kernel driver
<libv>
how many vendors sell adreno based hardware?
<libv>
and now count how many vendors sell mali based hardware.
<tfiga>
vendors of what?
<libv>
you clearly have not thought this through
<libv>
SoC vendors
<tfiga>
of course Adreno can be found only in Qualcomm's SoCs
<libv>
device makers are semi-irrelevant here
<libv>
so...
<libv>
you get one display engine, or a few small variations thereof
<tfiga>
but even Qualcomm's kernels are very different
<tfiga>
device makers tend to add their own stuff on top
<libv>
only in a limited fashion
<tfiga>
but yes, you're right
<libv>
and very few of it actually matters for the 3d driver
<tfiga>
it's worse with Mali
<libv>
of course i am, i have spent my last 3 years on this
<tfiga>
but not that much worse as it might appear
<tfiga>
Mali is Mali
<libv>
samsung
<libv>
allwinner
<libv>
rockchip
<libv>
mediatek
<tfiga>
SoCs vendors don't change the GPU itself
<tfiga>
they can put different integration glue
<tfiga>
but this can be easily abstracted
<libv>
but we are talking about the integration glue!
<libv>
yes, it gets abstracted, up to a point...
<libv>
up to the point where i have to deal with the issues
<libv>
and this is exactly what this whole discussion was about
<libv>
most of the code doesn't care
<libv>
but there is a bit of a hack going on at two points where the different vendor kernels need to be worked around
<libv>
but that is the least of all pains
<libv>
rewriting kernels all day long is not what i am in for
<libv>
fixing the worst issues, like with the odroid-3.0 tree, that's normal
<libv>
even though i still make a big stink about issues that daft
<libv>
(and endemic)
<libv>
but rewriting the display, media, 2d, and mali driver of every vendor kernel, for what could also be a dozen or so extra lines (will be more with dma-buf though), that's just not sensible
<tfiga>
well, if you can abstract those things on kernel level
<tfiga>
and keep the userspace clean, then it's fine
<libv>
why not just abstract at userspace, and save the user a kernel recompilation (that might not be possible)
<tfiga>
then the hacks would remain in vendor trees
<libv>
then i would have to hack every vendor tree
<libv>
and make sure that users have access to the hacked vendor trees
<tfiga>
or let anyone interested do that
<libv>
plus, most of the hacks can be re-used
<libv>
it's really not that insane a task in userspace
<libv>
i don't get why you some desperately cling on to this concept
<tfiga>
well, if it doesn't have any insane implications such as the need to operate on physical addresses, then yes
<libv>
if it were up to you, i would have to hack every single vendor tree of every single device out there, and keep up to date said trees
<libv>
i just need to pass the physical address back into the mali kernel allocator/mapper
<tfiga>
and you can always pass back something else
<libv>
but then i would need to hack every vendor tree of every device out there, and keep those patches or trees up to date for eternity
<tfiga>
as I said, it all depends on what you want to achieve
<libv>
i believe that i have repeated that many times now
<tfiga>
if you just want "freedom"
<libv>
or?
<tfiga>
then I guess it's ok
<libv>
if you just keep running after an unattainable goal?
<libv>
squeaking away all night
<libv>
occasionally stopping to stuff some nuts in your cheeks?
<tfiga>
whatever you prefer :)
<libv>
if the goal is to get a working gpu driver that many people could actually use, then you add a bit of compatibility glue in userspace to work with the vendor provided code
<libv>
rewriting everything on the planet is not going to get many results
<libv>
especially since such efforts are thrown in the bin in a few weeks time anyway
<tfiga>
anyway
<libv>
?
<libv>
heh
<tfiga>
I shouldn't really care
<libv>
only the kernel and the kernel way of thinking...
<tfiga>
that's not something that affects me personally
<libv>
i should've known better than waste my breath again
<tfiga>
sorry for wasting your time
<tfiga>
I understand your arguments and value them in some way
<tfiga>
but it's sad that people don't want to work with upstream
<tfiga>
keep up the good work anyway
<libv>
tfiga: oh, in my case, that relationship is inverse
<libv>
tfiga: ask yourself, why does google not know the word modesetting before 2004?
<tfiga>
hard to say, I haven't been following this topic for so long
<tfiga>
I'm talking based on what I can see now
<tfiga>
I don't have that much historical background
<tfiga>
although I can understand your concerns, because I too have been developing an open source graphics driver that were supposed to run on vendor kernel
<libv>
anyway, i believe that mesa should allow for external drivers
<libv>
and i know for a fact that that is not too hard to achieve
<tfiga>
but this is different from case to case, you have the point that in case of Mali there are too many different vendor trees to maintain
<libv>
it will make intels users much happier to not have to replace half their installation on a graphics driver update
<tfiga>
my case was simple in the aspect that there was just one vendor (Samsung) and the vendor tree was seriously broken even in terms of fbdev support
<tfiga>
so I needed to patch the kernel anyway
<libv>
sure, and it is good that you fix that one vendor tree
<libv>
but how many devices did that fix?
<libv>
how many users did that reach?
<libv>
one or two development boards?
<tfiga>
several modes based on that one SoC and probably few thousands users I'd say
<libv>
how long did it take for those changes to turn up in the wild?
<tfiga>
models*
<libv>
how long before those things were shipped in the images the device makers put out?
<tfiga>
not shipped
<tfiga>
that was just a community-based work
<libv>
and how many users went and threw away their old installations on their development boards to install the new images?
<tfiga>
we;re talking here about Android phones
<tfiga>
not development boards
<libv>
android phones is even worse
<libv>
the numbers are much smaller there still
<tfiga>
I agree
<libv>
so if you are solving the problem of userspace, and this is the biggest problem still, now that at least some vendors have been complying with the GPL in the last few years and some people have actually succeeded in getting their own built kernel on their devices...
<libv>
then you need to make sure that you do not depend on small kernel differences too much, and that you definitely not go rewrite half the kernel just to be able to show a stupid triangle and glmark2-es2
<tfiga>
again, if it doesn't seriously affect your userspace, it's fine
<libv>
you can abstract anywhere, and keep the workaround relatively self-contained and well documented
<libv>
everything else then becomes a performance issue
<tfiga>
I started the whole discussion as a result of seeing physical addresses in userspace
<libv>
and yes, physical addresses in userspace is bad, but that's how ARM has been doing it until, _perhaps_, very very recently
<libv>
_i_ need to tell the kernel, where to find the FB to map, it doesn't do that on its own
<tfiga>
personally I would prefer fixing something like this over the driver being a mesa driver
<libv>
it shouldn't either
<libv>
...
<libv>
that didn't fully parse
<tfiga>
I mean, physical addresses in userspace make a security issue
<libv>
but that's how the mali kernel driver works/worked
<tfiga>
and that's why I'd like to change them for something else
<liquidAcid>
mali r3p2 can use dmabuf just fine
<tfiga>
liquidAcid: I know there are better versions, but this is just an example
<libv>
tfiga: sure
<libv>
tfiga: but that doesn't mean that i should not support the broken way of doing things
<libv>
or should've waited 3 whole years for that to happen
<libv>
if the mali kernel driver requires the physical adress of the fb, then that is what it should get
<libv>
it sure as hell got it with the android kernel and with the binary driver
<libv>
perhaps through other means, but the kernel drivers i have worked with so far have all required intimate knowledge of where the fb physically lives
<libv>
liquidAcid: how old is r3p2?
<liquidAcid>
pretty old
<libv>
liquidAcid: what vendors kernels support r3p2?
<libv>
_all_ of them?
<liquidAcid>
that question doesn't make sense to me
<libv>
it does.
<tfiga>
but the point is that you didn't have to use that driver
<libv>
mali exists on many SoCs
<liquidAcid>
no, it doesn't
<liquidAcid>
you probably mean, what vendor kernels _include_ r3p2
<liquidAcid>
the support question can only be posed for userspace
<libv>
liquidAcid: userspace is tied almost 1-1 with kernel space in this case
<liquidAcid>
your point?
<libv>
you can only use r3p2 against a kernel that supports r3p2
<libv>
arm intelligently used enums for their ioctls
<libv>
so they happily shift around, even the versioning ioctl
<tfiga>
anyway, I agree that this is way too much work
<liquidAcid>
stil, i don't get your point -- i was only saying that even r3p2 supports dmabuf, so you don't have to rely on passing around physical address to userspace
<liquidAcid>
and probably r3p2 is not the earliest release that support dmabuf
<libv>
liquidAcid: but i do... _for_ _those_ _kernels_ _that_ _require_ _it_
<tfiga>
and I also agreed that those vendor drivers are enough to start some work
<liquidAcid>
but i'm too lazy atm to look at r3p1 and r3p1
<libv>
which is the whole point of the last hour
<libv>
tfiga: in case of mali-400, that's where it will have to remain
<tfiga>
but they should not be the ultimate goal, even though they might be a temporary goal
<libv>
tfiga: there is just no time or manpower available to change that
<libv>
t-series, who knows
<libv>
but given the amount of support i have received in doing lima, i'd say, forget it
<tfiga>
libv: right, that's sad
<libv>
that's reality, and that's my life.
<libv>
but i had the same happen to me when i came up with most of the core ideas behind modesetting, and indeed the term itself
<ssvb>
tfiga: things are going to improve if Samsung starts eating its own dog food and begins shipping kms enabled kernels with their top selling android devices :)
<tfiga>
ssvb: I'd say something, but unfortunately I can't
<ssvb>
whatever, until this happens, be ready to hear complaints :)
<tfiga>
well, I don't have anything to do with Android kernels, so I don't care too much
<ssvb>
neither do I
<tfiga>
but yes, things from mainline are hitting vendor kernels eventually
<tfiga>
libv: hopefully things will improve in future
<tfiga>
what's the problem with upstreaming lima?
<tfiga>
couldn't you keep all the hacks in a separate library, such as robclark keeps the support for kgls in libdrm?
<tfiga>
argh, s/such as/just as/
<libv>
tfiga: 3 years is a long time
<libv>
tfiga: rob happily works for redhat and gets to spend part of his time on freedreno
<libv>
tfiga: rpi just hired anholt to implement the broadcom driver
<libv>
arm mpd is fully against anything free for mali
<tfiga>
libv: I would say something again, but again I can't
<libv>
no SoC vendor would want to be seen dead in my vicinity
<ssvb>
Wizzup: if I understand it correctly, it is zero smem_len responsible for blowing up things, we don't really need the actual physical framebuffer address for exynos in fbdev/fbturbo ddx
<Wizzup>
alright, it seemed necessary to get it up currently at least
<Wizzup>
but yes, the commit mentions other ways to get that
<ssvb>
Wizzup: do you happen to know what are these screen_base/screen_size() functions? I can't find them in my fb.h or anywhere in /usr/include
<Wizzup>
Nope, sorry... I can have a look later, but it seems I'm already late going to bed
<ssvb>
but yes, if smem_len is zero, then we can try to guess it in some other ways, for example by doing calculations using width, height and color depth
<ssvb>
still this kernel change breaks the userland for no real reason
<Wizzup>
"security"
<ssvb>
there is no security added by trashing 'smem_len'
<Wizzup>
(I agree, hence the quotes)
<swabbles>
ssvb: makes sense @ smem_len.
liquidAcid has quit [Quit: Leaving]
<ssvb>
yeah, and I'm already fed up with broken fbdev kernel drivers (rockchip also has a ton of issues)
<ssvb>
the only practical solution that I see at the moment is a simple conformance checking application, which would help to expose common driver bugs