Creator CI20 status in 2023

[Arkadi Shishlov]

Hi,

I'd like to engage in a self-suffering activity of bringing semi-modern userland on CI20 to play with Rust on MIPS. I'd still be happy with stock Debian 8 image if I can run cross-compiled binaries there. Or with a Gentoo build [1] by Gabriele Svelto.

Linux on MIPS is possible with home network devices, yet too limiting and slow.

After reading wiki, forums, powervr-next info, and examining rootfs nand image I'd like to confirm:

- Debian 9 mipsel is possible with 3.18 kernel.

- HDMI, USB, sound works.

- There is some sort of functional OpenGL with PowerVR binary blobs from Imagination.

- What is it? Mesa libGL with proprietary parts in /usr/lib/mipsel-linux-gnu/sgx/? Working GLESv2, EGL?

- jz4780_dri.so likely incompatible with recent Xorg version?

- What about KMS - SDL2 kmsdrm without X?

- Working SPI bits are scattered over GitHub repos?

Also, anyone would like to part with their unused working CI20 for a reasonable compensation? (I know about RS and there is one v1 unit on eBay)

[1] https://www.setphaserstostun.org/pages/mips-creator-ci20-gentoo-resources/

[Paul Boddie]

On Sunday, 15 January 2023 17:25:57 CET Arkadi Shishlov wrote:
> Hi,
> I'd like to engage in a self-suffering activity of bringing semi-modern
> userland on CI20 to play with Rust on MIPS. I'd still be happy with stock
> Debian 8 image if I can run cross-compiled binaries there. Or with a Gentoo
> build [1] by Gabriele Svelto.
>
> Linux on MIPS is possible with home network devices, yet too limiting and
> slow.

Certainly, a Linux desktop experience is rather slow, even with mitigations
for the excessive demands of "modern" desktop software, Web browsers, and so
on, but I don't feel that Linux itself need be considered particularly slow.
My own interests would certainly have me agree with you about it being
limiting, however.

> After reading wiki, forums, powervr-next info, and examining rootfs nand
> image I'd like to confirm:
> - Debian 9 mipsel is possible with 3.18 kernel.

I think that Debian 9 (Stretch) should work, and I'm pretty sure that's the
version I last deployed on my CI20. As long as the distribution doesn't
require kernel features that are too modern, then I think 3.18 will remain
usable.

> - HDMI, USB, sound works.

On 3.18, yes.

HDMI support has been restored to the mainline kernel, but I personally
experience issues getting the clock frequencies configured acceptably. I made
a suggestion about remedying this that can be read via the mips-creator-ci20-
dev list, but the Linux kernel development process does not work in a way
where people can sensibly discuss improvements and reach a consensus, so "it
works for me" seems to have won the day. Or for me personally, it means that I
just patch the kernel and keep thinking about ignoring Linux altogether in
future.

I think that USB and sound should work in the mainline kernel. Certainly, the
USB keyboard and mouse support worked when I tested them. I don't think I have
sound plumbed in, given that I actually use a DVI-D connection to my monitor.

Note that I run distributions from SD card, not NAND. I don't remember whether
the CI20 was one of the systems that suffered from a decision made by the
Linux kernel developers where support for various NAND technologies was
spontaneously discarded.

> - There is some sort of functional OpenGL with PowerVR binary blobs from
> Imagination.
> - What is it? Mesa libGL with proprietary parts in
> /usr/lib/mipsel-linux-gnu/sgx/? Working GLESv2, EGL?
> - jz4780_dri.so likely incompatible with recent Xorg version?
> - What about KMS - SDL2 kmsdrm without X?

PowerVR support was certainly demonstrated at some point in the past (along
with hardware accelerated video decoding support). Nikolaus Schaller was
pursuing some work to get newer PowerVR versions working on a range of devices
including the CI20:

https://github.com/openpvrsgx-devgroup
https://lists.goldelico.com/mailman/listinfo.cgi/openpvrsgx-devgroup

I have glanced at the video decoding support, picking through the MPlayer code
that was made available. It is all a bit of a guessing game, and everyone
would arguably benefit from having access to the documentation for such
facilities.

> - Working SPI bits are scattered over GitHub repos?

Probably, yes. This is one thing I haven't really looked at, other than on
other Ingenic devices.

> Also, anyone would like to part with their unused working CI20 for a
> reasonable compensation? (I know about RS and there is one v1 unit on eBay)
>
> [1]
> https://www.setphaserstostun.org/pages/mips-creator-ci20-gentoo-resources/

I'm actually surprised that RS still have some.

Paul

[Graham Whaley]

Hi Arkadi,

I have a still-in-box early (first probably) release CI20 that I’d be happy to pass on, for postage cost only. I’m in the UK, so we’d have to figure out if that is even practical, depending on where you are :-) pm me and we can discuss.

Graham
(ex-tech lead for the Ci20 ;-) )


> Paul
>
>
> --
> You received this message because you are subscribed to the Google Groups "MIPS Creator CI20" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-c...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/mips-creator-ci20/2438436.5PWYf2ZXJI%40jason.

[pcer...@gmail.com]

Hi Paul,

> HDMI support has been restored to the mainline kernel, but I
> personally
> experience issues getting the clock frequencies configured
> acceptably. I made
> a suggestion about remedying this that can be read via the mips-
> creator-ci20-
> dev list, but the Linux kernel development process does not work in a
> way
> where people can sensibly discuss improvements and reach a consensus,
> so "it
> works for me" seems to have won the day. Or for me personally, it
> means that I
> just patch the kernel and keep thinking about ignoring Linux
> altogether in
> future.

That's very passive-aggressive. We can absolutely discuss improvements
and reach a consensus. IIRC I asked you if switching to a higher VPLL
frequency fixed your issue, and you never tested it.

-Paul

[Paul Cercueil]

Hi Arkadi,

Hi,

I'd like to engage in a self-suffering activity of bringing semi-modern userland on CI20 to play with Rust on MIPS. I'd still be happy with stock Debian 8 image if I can run cross-compiled binaries there. Or with a Gentoo build [1] by Gabriele Svelto.

Linux on MIPS is possible with home network devices, yet too limiting and slow.

After reading wiki, forums, powervr-next info, and examining rootfs nand image I'd like to confirm:

- Debian 9 mipsel is possible with 3.18 kernel.

I don't know what's the minimal kernel version required by Debian 9. But you could try by upgrading the installed Debian all the way to Debian 9.

If you need something more recent, you should definitely be able to use Debian 9 with the upstream kernel, with some rough edges.

 

- HDMI, USB, sound works.

Answering about the upstream kernel now.

HDMI is expected to work, but (as Paul said) some LCD panels will cause trouble, until the underlying issues are fixed.

USB should be working, same as Ethernet. WiFi/Bluetooth are broken with the upstream kernel but I'm going to send a few patches to make them work soon.

Audio is not working. Either via the jack port or HDMI.

 

- There is some sort of functional OpenGL with PowerVR binary blobs from Imagination.

- What is it? Mesa libGL with proprietary parts in /usr/lib/mipsel-linux-gnu/sgx/? Working GLESv2, EGL?

- jz4780_dri.so likely incompatible with recent Xorg version?

- What about KMS - SDL2 kmsdrm without X?

No OpenGL support with the upstream kernel, at all. There was a code drop for PowerVR recently (last year or so) so an open-source Mesa driver could exist one day, but it's not yet here and I don't think anyone is working on it.

With that said, you should be able to use Xorg with the modesetting driver. You also should be able to use Wayland based UIs with llvmpipe, but it most likely won't be a good experience.

The kms/drm backend of SDL2 requires a GPU, so unless you use llvmpipe, you cannot have SDL2 apps (or via Xorg).

 

- Working SPI bits are scattered over GitHub repos?

The upstream SPI driver works fine.

 

Also, anyone would like to part with their unused working CI20 for a reasonable compensation? (I know about RS and there is one v1 unit on eBay)

[1] https://www.setphaserstostun.org/pages/mips-creator-ci20-gentoo-resources/

Depending on what you actually want to do, have a look at the Anbernic RG-350 handheld. It's a JZ4770 SoC (one generation below), has working audio, HDMI (720p max), USB, open-source GPU driver capable of EGL+GLESv2 (etnaviv), supports SDL/SDL2, runs upstream Linux and has an updated toolchain available. If you want to play with writing Rust games, it should be a much better platform.

The CI20 will be much better if you need to use it more like a desktop, or you need to connect stuff to the pins. But upstream Linux support overall is in a rough shape.

Cheers,

-Paul

[Arkadi Shishlov]

On Monday, 16 January 2023 at 18:23:49 UTC+2 pcer...@gmail.com wrote:

There was a code drop for PowerVR recently (last year or so) so an open-source Mesa driver could exist one day, but it's not yet here and I don't think anyone is working on it.

https://gitlab.freedesktop.org/frankbinns/powervr/-/commits/powervr-next

AFAIK, it is not for SGX.

 

With that said, you should be able to use Xorg with the modesetting driver. You also should be able to use Wayland based UIs with llvmpipe, but it most likely won't be a good experience.

llvmpipe works on MIPS? Indeed it will be hardly usable for desktop.

 

The kms/drm backend of SDL2 requires a GPU, so unless you use llvmpipe, you cannot have SDL2 apps (or via Xorg).

Looks like SDL3 will change that

https://github.com/libsdl-org/SDL/issues/6570#issuecomment-1323154215

(if the app doesn't depend on the OpenGL itself)

  

Depending on what you actually want to do, have a look at the Anbernic RG-350 handheld. It's a JZ4770 SoC (one generation below), has working audio, HDMI (720p max), USB, open-source GPU driver capable of EGL+GLESv2 (etnaviv), supports SDL/SDL2, runs upstream Linux and has an updated toolchain available. If you want to play with writing Rust games, it should be a much better platform.

Thanks for the pointer, I didn't knew about Anbernic option.

I have original A-320 Dingoo though.

[Paul Boddie]

On Monday, 16 January 2023 16:51:25 CET pcer...@gmail.com wrote:
>
> That's very passive-aggressive.

If it is then it is merely a consequence of operating in a passive-aggressive
environment. So, if anything, that just helps to make my point about the
attractiveness of Linux kernel development for me. Great if it works for you,
though.

> We can absolutely discuss improvements and reach a consensus. IIRC I asked
> you if switching to a higher VPLL frequency fixed your issue, and you never
> tested it.

My impression was that you were pushing the fix out to U-Boot, where the
frequency is set, rather than addressing the way that the frequency
calculation is done. Because there certainly is a discussion to be had about
whether that calculation is done appropriately. Otherwise, everything would
just work and not just for people whose hardware happens to have the right
characteristics.

Then again, on the topic of being able to "discuss improvements and reach a
consensus", it is informative to review a mail you sent back in September 2020
where, in response to requests for discussion about how various patches were
done, you wrote that you didn't care and that we were apparently to "email the
LKML" with our concerns. This after being falsely accused of wanting other
people to write our patches for us and getting a lecture about the burden of
software maintenance. By the way, I got considerably more constructive
feedback from various DRI developers, but I suppose they must be a soft touch
or something.

The reason why the choice of kernels is a vendor 3.18 kernel and a mainline
kernel that doesn't support the CI20 fully, despite the persistence of people
whose efforts you seem to routinely denigrate, is that when a lot of the
original work was submitted upstream, the response was (predictably) that the
code used some deprecated interfaces and needed redoing. So it was thrown back
over the wall to people who were no longer going to be paid to work on it, and
they sensibly got on with the rest of their lives. Someone else more recently
made a similar choice just prior to you dishing out your lecture on the hard
realities of Linux kernel development.

All of that is frustrating for those of us who wanted to pick up the original
work and ensure that the hardware avoids obsolescence, but I now regard their
example as a form of generally sound advice that also happens to reinforce
what I recently wrote about where I might prioritise my own efforts in future.

Paul

[pcer...@gmail.com]

Le lundi 16 janvier 2023 à 18:54 +0100, Paul Boddie a écrit :
> On Monday, 16 January 2023 16:51:25 CET pcer...@gmail.com wrote:
> >
> > That's very passive-aggressive.
>
> If it is then it is merely a consequence of operating in a passive-
> aggressive
> environment. So, if anything, that just helps to make my point about
> the
> attractiveness of Linux kernel development for me. Great if it works
> for you,
> though.

It doesn't really help, no.

> > We can absolutely discuss improvements and reach a consensus. IIRC
> > I asked
> > you if switching to a higher VPLL frequency fixed your issue, and
> > you never
> > tested it.
>
> My impression was that you were pushing the fix out to U-Boot, where
> the
> frequency is set, rather than addressing the way that the frequency
> calculation is done. Because there certainly is a discussion to be
> had about
> whether that calculation is done appropriately. Otherwise, everything
> would
> just work and not just for people whose hardware happens to have the
> right
> characteristics.

No, I don't think I ever said that the fix should be in u-boot. I
believe that the bootloader should only do the bare minimum, so the
kernel should set up the hardware so that it works properly.

As for how the calculation is done, that's a topic that should be
discussed with the clk maintainers. From what I know the policy is that
a clock should never go above the value set in clk_set_rate().

> Then again, on the topic of being able to "discuss improvements and
> reach a
> consensus", it is informative to review a mail you sent back in
> September 2020
> where, in response to requests for discussion about how various
> patches were
> done, you wrote that you didn't care and that we were apparently to
> "email the
> LKML" with our concerns. This after being falsely accused of wanting
> other
> people to write our patches for us and getting a lecture about the
> burden of
> software maintenance. By the way, I got considerably more
> constructive
> feedback from various DRI developers, but I suppose they must be a
> soft touch
> or something.

You'll have to point to the actual email to refresh everybody's memory.

The other DRI maintainers don't have to maintain the patches you send.
I do. If your idea of a consensus is that you push whatever crap you
want and I'm the one who has to dedicate time and effort to clean up
the mess, then no thank you.

If you work your patches so that they will result in little to no
maintenance over time, then I will gladly accept them. I was happy to
eventually merge the HDMI patchset.

And what's wrong with asking you to email the LKML with your concerns?
I don't have the answer to everything, if we're discussing technical
topics related to Linux development, it is normal to ask other
maintainers (or experts in their respective field or subsystem) their
input.

The original work got a lot of drivers upstream, some needed redoing,
yes. But a big part of the 3.x drivers were simply not even sent
upstream. Maybe they planned it, maybe not, but the CI20 project was
scraped before that, which left us with almost inexistant support in
the upstream kernel.

You seem to conveniently forget that since then, I have been the one,
on my free time and unpaid, writing drivers and slowly but surely
bringing the upstream kernel to the CI20. I don't think you realize the
enormous amount of work that is. We're talking 700+ patches here, most
of which took many revisions before being eventually merged.

I do not try to denigrate the efforts of people trying to pick up the
work and bring back the CI20 alive. I am one of these people. If
anything, you are denigrating my work. A handful of others sent patches
and drivers, some which were merged at once, and some which were merged
after a few revisions. Nobody threw a tantrum when I told them that
their patch needed some more work, and none of them demanded me to
throw in the work they wouldn't do.

-Paul

[Paul Boddie]

On Monday, 16 January 2023 22:43:20 CET pcer...@gmail.com wrote:
>
> No, I don't think I ever said that the fix should be in u-boot. I
> believe that the bootloader should only do the bare minimum, so the
> kernel should set up the hardware so that it works properly.
>
> As for how the calculation is done, that's a topic that should be
> discussed with the clk maintainers. From what I know the policy is that
> a clock should never go above the value set in clk_set_rate().

Well, I don't know what the policy is because I do not "live" this stuff. All
I noted was that when the pixel clock frequency is obtained as part of a
series of calculations, a divisor gets calculated using a "ceiling" division
operation, and this is then used by the SoC to divide the input frequency so
that it ends up as a value lower than it needs to be.

Given that you are by now presumably very familiar with various pixel clock
constraints in Ingenic SoCs, where frequencies are required to be greater than
a given threshold, I thought that this might be of concern, but instead it was
simply noted that the parent clock frequency is set by U-Boot, and there were
some vague remarks about resolutions supported by my display and me finding a
suitable parent clock frequency.

So it is interesting that only now do you bring up the way the frequency is
calculated, which is what I spent quite a bit of time explaining in the first
place.

[...]

> You'll have to point to the actual email to refresh everybody's memory.

It was a private mail to me and one or two other people. Look it up in your
own records if you want to refer to it.

> The other DRI maintainers don't have to maintain the patches you send.
> I do. If your idea of a consensus is that you push whatever crap you
> want and I'm the one who has to dedicate time and effort to clean up
> the mess, then no thank you.

No, that is not my idea of a consensus. But thanks for projecting motivations
onto other people in objectionable terms once again.

> If you work your patches so that they will result in little to no
> maintenance over time, then I will gladly accept them. I was happy to
> eventually merge the HDMI patchset.

What started off as a simple driver specialisation ended up as a colossal
exercise involving endless rounds of patch versions, including adapting to new
interfaces because of the endless API churn, and so on. It was an absurdly
inefficient use of time and effort. And even when the patchset was merged and
everyone happily reported that it worked for them, it didn't work for me. But
I suppose if software doesn't work for people, no maintenance is required to
meet their needs, with the ultimate goal of zero users and zero maintenance.

> And what's wrong with asking you to email the LKML with your concerns?
> I don't have the answer to everything, if we're discussing technical
> topics related to Linux development, it is normal to ask other
> maintainers (or experts in their respective field or subsystem) their
> input.

I'm not dealing with the LKML, so unless they are deciding how you are to
conduct yourself, and not merely with regard to the patch acceptance
procedure, why should I take my concerns to them? In any case, there is no
need to copy any particular adversarial approach to the drafting of patches,
which is what I largely object to, making this observation in general about
Linux kernel development.

[...]

> The original work got a lot of drivers upstream, some needed redoing,
> yes. But a big part of the 3.x drivers were simply not even sent
> upstream. Maybe they planned it, maybe not, but the CI20 project was
> scraped before that, which left us with almost inexistant support in
> the upstream kernel.
>
> You seem to conveniently forget that since then, I have been the one,
> on my free time and unpaid, writing drivers and slowly but surely
> bringing the upstream kernel to the CI20. I don't think you realize the
> enormous amount of work that is. We're talking 700+ patches here, most
> of which took many revisions before being eventually merged.

I do respect the effort you have put into maintaining Ingenic support in the
kernel. A lot of Ingenic support was originally present for the Ben NanoNote,
but the inevitable kernel churn ended up breaking a lot of functionality. As
for whether I "conveniently forget" anything, let it not be forgotten that I
and others submitting patches are also doing this off our own backs.

Let it also not be forgotten that every time you take the high-handed attitude
that we are somehow freeloading, you neglect that some of us are not even
doing this for our own benefit. I mean, I am only trying to make contributions
so that people have a chance to use this hardware again with a vaguely recent
kernel, but I am not likely to be using such a kernel myself. I am mostly
trying to help other people who want or need to see this as a possibility for
themselves.

Previously, you stated in your lecture about kernel discipline (again, look it
up in your sent mail folder) that everyone has "our own stuff", but this is
largely not even "my own stuff": it is mostly stuff developed by other people
that is being revived or adapted so that devices like the CI20 don't just get
thrown in the trash. I don't think anyone actually asked for special treatment
or for patches to be routinely rewritten, but I do think that they asked for a
degree of understanding and patience and not to have motivations projected
onto them so that they can be berated with exclamations like "Get down to
Earth."

> I do not try to denigrate the efforts of people trying to pick up the
> work and bring back the CI20 alive. I am one of these people. If
> anything, you are denigrating my work. A handful of others sent patches
> and drivers, some which were merged at once, and some which were merged
> after a few revisions. Nobody threw a tantrum when I told them that
> their patch needed some more work, and none of them demanded me to
> throw in the work they wouldn't do.

Again, no-one demanded anything from you. And again, this is just you
projecting motivations onto people who have been attempting to put together
patches and get feedback about them. In your little lecture, you also said
that you would rather people not bother engaging in such efforts, speculating
that maybe someone might "take the time to do it properly, in months or years
from now". Well, good luck following up with anyone with first-hand knowledge
of some of this functionality after "years from now" when they long ago
sensibly disengaged from the whole circus.

Of course, such sentiments are rather familiar from the Linux kernel scene,
recalling similar attitudes about licence compliance, companies violating the
licensing terms of the kernel, and general apathy towards people who bought
products but were denied corresponding source code. Apparently, everything
will be better in future and with future products. And those sentiments are
also pretty familiar elsewhere in various Free Software activities, leading to
absurd situations involving companies who actually employ developers from
certain key projects, with those companies having their product development
stalled because those developers or their peers want to take work and do it
their way and on their own schedule.

There is a great deal of dismissiveness about vendor kernels, with the
insinuation that they must come from low-quality developers at low-end
companies who don't have the skills to "do it properly", when in fact those
developers and those companies actually have to ship a product that works,
rather than wait for some kind of work in progress to be mostly functional in
a few years time. I believe that such considerations were pointed out to you
on at least one occasion, and it should be noted that most people in this
forum with a continuing interest in the viability of the CI20 (and, indeed,
most people in any product-specific forum) probably prioritise such
considerations - and a working device - over the ambling roadmap of the Linux
kernel and the shifting priorities of its custodians.

Recently, I became aware of an interesting hardware project involving an
Ingenic SoC. That project apparently experienced significant setbacks due to
deficiencies in the mainline kernel, leading to prolonged periods of debugging
and eventually the use of forward-ported vendor functionality that will
presumably never get merged for future kernel releases. It was said that the
instigator of this project tried to get some feedback on their not
inconsiderable issues but were met with apathy.

That story did not surprise me in the least. My commiserations to that person
if they are reading this. I bet they can look forward to having their efforts
denigrated and their motivations mischaracterised, too, if they haven't
already had the pleasure of that experience.

Paul

[pcer...@gmail.com]

Le mardi 17 janvier 2023 à 00:46 +0100, Paul Boddie a écrit :
> On Monday, 16 January 2023 22:43:20 CET pcer...@gmail.com wrote:
> >
> > No, I don't think I ever said that the fix should be in u-boot. I
> > believe that the bootloader should only do the bare minimum, so the
> > kernel should set up the hardware so that it works properly.
> >
> > As for how the calculation is done, that's a topic that should be
> > discussed with the clk maintainers. From what I know the policy is
> > that
> > a clock should never go above the value set in clk_set_rate().
>
> Well, I don't know what the policy is because I do not "live" this
> stuff. All
> I noted was that when the pixel clock frequency is obtained as part
> of a
> series of calculations, a divisor gets calculated using a "ceiling"
> division
> operation, and this is then used by the SoC to divide the input
> frequency so
> that it ends up as a value lower than it needs to be.

And that sounds expected, yes.

> Given that you are by now presumably very familiar with various pixel
> clock
> constraints in Ingenic SoCs, where frequencies are required to be
> greater than
> a given threshold, I thought that this might be of concern, but
> instead it was
> simply noted that the parent clock frequency is set by U-Boot, and
> there were
> some vague remarks about resolutions supported by my display and me
> finding a
> suitable parent clock frequency.
>
> So it is interesting that only now do you bring up the way the
> frequency is
> calculated, which is what I spent quite a bit of time explaining in
> the first
> place.

And what's so interesting about it?

I would have brought it up in a follow-up email, if my suggestion of
setting the VPLL much higher didn't fix your issue, but you didn't even
bother to try.

>
> [...]
>
> > You'll have to point to the actual email to refresh everybody's
> > memory.
>
> It was a private mail to me and one or two other people. Look it up
> in your
> own records if you want to refer to it.
>
> > The other DRI maintainers don't have to maintain the patches you
> > send.
> > I do. If your idea of a consensus is that you push whatever crap
> > you
> > want and I'm the one who has to dedicate time and effort to clean
> > up
> > the mess, then no thank you.
>
> No, that is not my idea of a consensus. But thanks for projecting
> motivations
> onto other people in objectionable terms once again.

There's a difference between sending me a crappy patch, and trying to
shove it down my throat.

Patches are almost never perfect the first round, and that's perfectly
fine. After a few revisions they are generally in a good shape and can
be merged.

So yes, motivational speech here, do send me crappy patches, if you can
take the constructive criticism and do the work to clean them until
they are mergeable.

Do not send me a crappy patch if you don't have the *motivation* to
continue the work until it is merged.

> > If you work your patches so that they will result in little to no
> > maintenance over time, then I will gladly accept them. I was happy
> > to
> > eventually merge the HDMI patchset.
>
> What started off as a simple driver specialisation ended up as a
> colossal
> exercise involving endless rounds of patch versions, including
> adapting to new
> interfaces because of the endless API churn, and so on. It was an
> absurdly
> inefficient use of time and effort. And even when the patchset was
> merged and
> everyone happily reported that it worked for them, it didn't work for
> me. But

The colossal exercise would have been a much lighter task if you didn't
spend so much time arguing with our criticism on your patches.

The facts are that your first patchset revisions were maybe adding HDMI
support to the CI20, but were also breaking other stuff, and you didn't
even seem to care.

> I suppose if software doesn't work for people, no maintenance is
> required to
> meet their needs, with the ultimate goal of zero users and zero
> maintenance.

That's absolutely false. You can have a broken driver, with zero users,
and still need to put a lot of maintenance work.

Then you can have a somewhat broken driver, with plenty of users, that
doesn't require much maintenance if any. The fact that some
functionality is broken has nothing to see with code maintenance.

> > And what's wrong with asking you to email the LKML with your
> > concerns?
> > I don't have the answer to everything, if we're discussing
> > technical
> > topics related to Linux development, it is normal to ask other
> > maintainers (or experts in their respective field or subsystem)
> > their
> > input.
>
> I'm not dealing with the LKML, so unless they are deciding how you
> are to
> conduct yourself, and not merely with regard to the patch acceptance
> procedure, why should I take my concerns to them? In any case, there
> is no
> need to copy any particular adversarial approach to the drafting of
> patches,
> which is what I largely object to, making this observation in general
> about
> Linux kernel development.

Well, you did send your patches to the LKML, didn't you? So you are
already dealing with the LKML in a way, and I don't understand what's
your big problem with voicing technical concerns to the right people.

Isn't that the case for us all? I'm not really using the CI20 for
anything. And how is that even relevant?

> Previously, you stated in your lecture about kernel discipline
> (again, look it
> up in your sent mail folder) that everyone has "our own stuff", but
> this is
> largely not even "my own stuff": it is mostly stuff developed by
> other people
> that is being revived or adapted so that devices like the CI20 don't
> just get
> thrown in the trash. I don't think anyone actually asked for special
> treatment
> or for patches to be routinely rewritten, but I do think that they
> asked for a
> degree of understanding and patience and not to have motivations
> projected
> onto them so that they can be berated with exclamations like "Get
> down to
> Earth."

You didn't receive special treatment. And I was patient, I kept
reviewing the patchsets again and again until it was eventually merged.

> > I do not try to denigrate the efforts of people trying to pick up
> > the
> > work and bring back the CI20 alive. I am one of these people. If
> > anything, you are denigrating my work. A handful of others sent
> > patches
> > and drivers, some which were merged at once, and some which were
> > merged
> > after a few revisions. Nobody threw a tantrum when I told them that
> > their patch needed some more work, and none of them demanded me to
> > throw in the work they wouldn't do.
>
> Again, no-one demanded anything from you. And again, this is just you
> projecting motivations onto people who have been attempting to put
> together
> patches and get feedback about them. In your little lecture, you also
> said
> that you would rather people not bother engaging in such efforts,
> speculating
> that maybe someone might "take the time to do it properly, in months
> or years
> from now". Well, good luck following up with anyone with first-hand
> knowledge
> of some of this functionality after "years from now" when they long
> ago
> sensibly disengaged from the whole circus.

Arguing with me for not merging the patches when I say they are not
ready yet, is demanding me to throw in the extra work to fix them.

You (or Nikolaus) even stated in one of your emails that as the
maintainer I was the best placed to update the code to fit the
standards. That may be true, but that doesn't mean I'm okay with you
dumping the extra work on me.

And yes, I will say it again, if you dump patches on me and expect me
to fix them for you, then don't bother, I won't take them.

If you are ready to go all the way until the patch is merged, then yes
please, send me patches.

> Of course, such sentiments are rather familiar from the Linux kernel
> scene,
> recalling similar attitudes about licence compliance, companies
> violating the
> licensing terms of the kernel, and general apathy towards people who
> bought
> products but were denied corresponding source code. Apparently,
> everything
> will be better in future and with future products. And those
> sentiments are
> also pretty familiar elsewhere in various Free Software activities,
> leading to
> absurd situations involving companies who actually employ developers
> from
> certain key projects, with those companies having their product
> development
> stalled because those developers or their peers want to take work and
> do it
> their way and on their own schedule.

These companies are very short-sighted and their developers know
better. Doing it the right way from the start is always better in the
long run.

> There is a great deal of dismissiveness about vendor kernels, with
> the
> insinuation that they must come from low-quality developers at low-
> end
> companies who don't have the skills to "do it properly", when in fact
> those
> developers and those companies actually have to ship a product that
> works,
> rather than wait for some kind of work in progress to be mostly
> functional in
> a few years time. I believe that such considerations were pointed out
> to you
> on at least one occasion, and it should be noted that most people in
> this
> forum with a continuing interest in the viability of the CI20 (and,
> indeed,
> most people in any product-specific forum) probably prioritise such
> considerations - and a working device - over the ambling roadmap of
> the Linux
> kernel and the shifting priorities of its custodians.

Prioritizing a working device is fine, but you can ship a device that
works while still working on the code so that it is sustainable in the
long run. MIPS guys were doing that, working on their vendor 3.x
kernel while upstreaming the drivers on the side, until they eventually
disbanded.

> Recently, I became aware of an interesting hardware project involving
> an
> Ingenic SoC. That project apparently experienced significant setbacks
> due to
> deficiencies in the mainline kernel, leading to prolonged periods of
> debugging
> and eventually the use of forward-ported vendor functionality that
> will
> presumably never get merged for future kernel releases. It was said
> that the
> instigator of this project tried to get some feedback on their not
> inconsiderable issues but were met with apathy.

Care to point out the mailing list thread where the instigator of this
project tries to get some feedback? Because I'm genuinely curious, and
that wasn't in a personal email addressed to me.

> That story did not surprise me in the least. My commiserations to
> that person
> if they are reading this. I bet they can look forward to having their
> efforts
> denigrated and their motivations mischaracterised, too, if they
> haven't
> already had the pleasure of that experience.

The only efforts I'm denigrating are your efforts to force me to take a
half-baked patchset and fix it myself.

I won't denigrate efforts to get a functionality upstream, if you are
actually ready to work with us towards that goal without trying to take
shortcuts.

That's nothing personal, so as long as you understand that, I have no
animosity towards you or any other contributor and I won't have any
problems working with you on that HDMI problem or anything else in the
future.

-Paul

[Arkadi Shishlov]

On Sunday, 15 January 2023 at 20:26:33 UTC+2 pa...@boddie.org.uk wrote:

https://github.com/openpvrsgx-devgroup
https://lists.goldelico.com/mailman/listinfo.cgi/openpvrsgx-devgroup

If, as a developer, I want to contribute small bits to CI20 upstream kernel work, where should I engage with code?

I suppose I do not want LKML directly, but I'd like to work with "board maintainer" or subsystem maintainer in a modern PR workflow, or...?

openpvrsgx-devgroup group? Some kernel tree on Freedesktop's GitLab?

What about Letux kernel?

https://elinux.org/CI20_upstream

https://projects.goldelico.com/p/gta04-kernel/

BTW, another place with CI20 in stock - one v2 unit:

https://www.hellasdigital.gr/electronics/microcontrollers/?features_hash=43-305

[Paul Boddie]

On Tuesday, 17 January 2023 12:57:19 CET you wrote:
> Le mardi 17 janvier 2023 à 00:46 +0100, Paul Boddie a écrit :
> >
> > So it is interesting that only now do you bring up the way the
> > frequency is calculated, which is what I spent quite a bit of time
> > explaining in the first place.
>
> And what's so interesting about it?
>
> I would have brought it up in a follow-up email, if my suggestion of
> setting the VPLL much higher didn't fix your issue, but you didn't even
> bother to try.

If I didn't bother to try, it might have been because the functionality worked
with the configured frequency under the vendor kernel. So, this was a form of
regression that needed some investigation because we had gone from a system
that worked under a range of circumstances to one that doesn't. And what if I
had changed the frequency and it had worked? Would that have actually fixed
the underlying problem? Or would it have merely added another person to the
"works for me" column?

[...]

> > > The other DRI maintainers don't have to maintain the patches you
> > > send. I do. If your idea of a consensus is that you push whatever crap
> > > you want and I'm the one who has to dedicate time and effort to clean
> > > up the mess, then no thank you.
> >
> > No, that is not my idea of a consensus. But thanks for projecting
> > motivations
> > onto other people in objectionable terms once again.
>
> There's a difference between sending me a crappy patch, and trying to
> shove it down my throat.

No-one did any such thing. Since there is seemingly no venue for discussing
how functionality can be improved and that everything has to be framed in
terms of upstream patches, patches were duly delivered in such a fashion with
the expectation that they would be reviewed, rejected and refined. If you then
ended up getting largely the same patchset over and over again, with everybody
getting tired of the whole exercise, maybe it says something about the process
rather than, or as well as, the people involved.

> Patches are almost never perfect the first round, and that's perfectly
> fine. After a few revisions they are generally in a good shape and can
> be merged.
>
> So yes, motivational speech here, do send me crappy patches, if you can
> take the constructive criticism and do the work to clean them until
> they are mergeable.
>
> Do not send me a crappy patch if you don't have the *motivation* to
> continue the work until it is merged.

Again, this is just you mischaracterising the motivations and output of other
people. Everyone evidently had the motivation to get it merged because it was
merged. That doesn't mean that we all have to pretend it was an enjoyable
exercise. Personally, my life would have been more enjoyable had I not
bothered.

[...]

> The colossal exercise would have been a much lighter task if you didn't
> spend so much time arguing with our criticism on your patches.
>
> The facts are that your first patchset revisions were maybe adding HDMI
> support to the CI20, but were also breaking other stuff, and you didn't
> even seem to care.

I will note that my contributions were folded into a much larger patchset, but
I don't think I personally ever spent "so much time arguing" with any
criticism. I did complain about the development process being poor and that I
"always manage to feel guilty asking for cooperation to get improvements made
to Linux". As far as I am concerned, that is all fair comment.

As for breaking stuff, we encountered your DRM driver that didn't support
various aspects of the CI20 at all, such as the extended DMA descriptors and
various differences with LCD controller registers. If there is no constructive
way of collaborating other than sending patches then having those patches
break stuff is just a natural consequence of having to operate in such a
collaboration-poor environment.

> > I suppose if software doesn't work for people, no maintenance is
> > required to meet their needs, with the ultimate goal of zero users and
> > zero maintenance.
>
> That's absolutely false. You can have a broken driver, with zero users,
> and still need to put a lot of maintenance work.
>
> Then you can have a somewhat broken driver, with plenty of users, that
> doesn't require much maintenance if any. The fact that some
> functionality is broken has nothing to see with code maintenance.

My point was that if a regression breaks people's systems and they decide to
just give up and use something else, then you don't have to worry about those
users' needs. Keep going along that path and you won't have to worry about
anyone's needs.

[...]

> > I'm not dealing with the LKML, so unless they are deciding how you
> > are to conduct yourself, and not merely with regard to the patch
> > acceptance procedure, why should I take my concerns to them? In any case,
> > there is no need to copy any particular adversarial approach to the
> > drafting of patches, which is what I largely object to, making this
> > observation in general about Linux kernel development.
>
> Well, you did send your patches to the LKML, didn't you? So you are
> already dealing with the LKML in a way, and I don't understand what's
> your big problem with voicing technical concerns to the right people.

It wasn't about "technical concerns", though, was it? Your suggestion was
effectively that if we didn't like the way collaboration was being done, we
should take it up with the management. If you don't think that was what you
communicated, maybe you should review what you wrote. For the benefit of
others, here it is:

"I don't care about your point of view on how things should be managed.
Things are what they are, for reasons."

To me, it sounded rather like someone saying that other people behave in a
particular way - again, beyond any technical procedure - and although that
person has it in their power to behave differently, they will just copy the
dominant social behaviour. There is plenty of scope for behaving differently,
as other people have demonstrated even within the constraints of the Linux
kernel effort.

And for reference, here is the text I wrote to which you were responding:

"I am not demanding that anyone merge my code, and I have been quite willing
to accommodate various demands so that everyone feels comfortable about any of
my code going into the kernel, but there has to be a tangible process that
leads to the objective being reached."

But, of course, you prefer to frame it all as people not trying hard enough,
following the dominant social culture which can be illustrated as follows:

https://lore.kernel.org/lkml/2015031007...@phenom.ffwll.local/

As to whether people did things the right way or not, to those who care about
whether any given product is viable, it just shows that the culture and its
processes did not work for a specific product and arguably do not work for the
majority of products. That is observable fact confirmed by the very topic of
the first message in this thread.

[...]

> Isn't that the case for us all? I'm not really using the CI20 for
> anything. And how is that even relevant?

Because you continually frame all of this as people wanting something for
their own benefit. As I noted above, I don't get any real benefit from
spending hours upon hours of my time trying to assist other people, doing work
that I wouldn't want to do even if it were paid, only to have my motivations
mischaracterised and to be given yet more of the same, with only my own sense
of obligation keeping me going until a point where there is hopefully going to
be a result.

[...]

> > And those sentiments are also pretty familiar elsewhere in various Free
> > Software activities, leading to absurd situations involving companies who
> > actually employ developers from certain key projects, with those companies
> > having their product development stalled because those developers or their
> > peers want to take work and do it their way and on their own schedule.
>
> These companies are very short-sighted and their developers know
> better. Doing it the right way from the start is always better in the
> long run.

No, those companies are, in fact, the ones waiting for "upstream" to dictate
how they will deliver their products and/or upsetting their employees and
their divided loyalties. So, they are doing things in precisely the way you
would prefer them to. Meanwhile, Google, Samsung and other companies make
billions of dollars from selling products using vendor kernels. So short-
sighted of them to make products that work and are available when they are
scheduled to go on sale!

[...]

> Care to point out the mailing list thread where the instigator of this
> project tries to get some feedback? Because I'm genuinely curious, and
> that wasn't in a personal email addressed to me.

I didn't look up the mailing list thread, but here you go:

https://hackaday.io/project/185645-notkia-name-change-planned/log/212603-dismissing-the-new-arch-the-evb-and-bitter-fighting-with-linux-drivers-2022-10-09

And before you take offense at what you perceive as a remark directed at you
personally, let me spell out that it was a remark about the culture and how
well it works for those interacting with it. You can decide for yourself
whether you want to defend that culture or whether you think that responding
to this person's concerns might actually be beneficial to all parties
including yourself.

[...]

> That's nothing personal, so as long as you understand that, I have no
> animosity towards you or any other contributor and I won't have any
> problems working with you on that HDMI problem or anything else in the
> future.

Well, that is nice to hear. I personally don't see myself spending any time
contributing to Linux in the future. I have spent substantial amounts of time
investigating, troubleshooting, and fixing functionality and the whole
exercise has arguably been detrimental to my quality of life.

Every time I have looked at some issue or other, I started out with a brief
feeling of optimism that someone's situation will be marginally improved by my
efforts, and then I quickly got the sensation of dread and even depression
about having to look at it all again. Indeed, going through who apparently
said what to whom going back years - because that is how long these exercises
drag out - is itself depressing, and I do not use the term lightly.

Maybe you will continue to conveniently frame such experiences in terms of the
personal failures of others, but I suppose you must tell yourself whatever you
want to believe to keep yourself invested in what you are doing. I will simply
restate what I said at the beginning of all this, that "ignoring Linux
altogether in future" is going to be my personal strategy from now on, the
rationale for which mostly having nothing to do with Linux at all.

Paul

[pcer...@gmail.com]

No, we went from a system that did not support HDMI, to a system that
somewhat supports HDMI.

Unless the screen advertise a range of acceptable values, which it
doesn't (AFAIK), then there is no way to actually fix the problem, just
ways to mitigate it by reducing the clock delta vs. the requested
value.

You end up with almost the same patchset over and over again, that's
perfectly normal and expected, as it gets refined over time. If you did
end up with a very different patchset every time then that would mean
trouble.

You make some edits, and the edits themselves have to be reviewed, and
may need extra edits, etc. until the code is mergeable.

> > Patches are almost never perfect the first round, and that's
> > perfectly
> > fine. After a few revisions they are generally in a good shape and
> > can
> > be merged.
> >
> > So yes, motivational speech here, do send me crappy patches, if you
> > can
> > take the constructive criticism and do the work to clean them until
> > they are mergeable.
> >
> > Do not send me a crappy patch if you don't have the *motivation* to
> > continue the work until it is merged.
>
> Again, this is just you mischaracterising the motivations and output
> of other
> people. Everyone evidently had the motivation to get it merged
> because it was
> merged. That doesn't mean that we all have to pretend it was an
> enjoyable
> exercise. Personally, my life would have been more enjoyable had I
> not
> bothered.

Yes, I think that once it was clear that I wouldn't merge the patches
as-is, that some work was needed and I wasn't going to be the one doing
it, we did work on the patches all the way until they were merged.

Except for the argumental emails, which were few and in-between, the
vast majority of the discussions on the HDMI patchsets between me and
Nikolaus were code-focused and very cordial. We probably don't have a
fond memory of it, but it wasn't that bad either.

>
> [...]
>
> > The colossal exercise would have been a much lighter task if you
> > didn't
> > spend so much time arguing with our criticism on your patches.
> >
> > The facts are that your first patchset revisions were maybe adding
> > HDMI
> > support to the CI20, but were also breaking other stuff, and you
> > didn't
> > even seem to care.
>
> I will note that my contributions were folded into a much larger
> patchset, but
> I don't think I personally ever spent "so much time arguing" with any
> criticism. I did complain about the development process being poor
> and that I
> "always manage to feel guilty asking for cooperation to get
> improvements made
> to Linux". As far as I am concerned, that is all fair comment.

Well, I gave you criticism about your LCD pixclock problem, and instead
of trying the alternative I suggested, you keep arguing that "if the
vendor kernel does it this way then that's how it should be done".

> As for breaking stuff, we encountered your DRM driver that didn't
> support
> various aspects of the CI20 at all, such as the extended DMA
> descriptors and
> various differences with LCD controller registers. If there is no
> constructive
> way of collaborating other than sending patches then having those
> patches
> break stuff is just a natural consequence of having to operate in
> such a
> collaboration-poor environment.

Yes, and it is an accepted consequence: nobody will shout at you if you
accidentally break stuff in a V1 patchset, but the final patchset must
not break anything.

The other side of the coin, is that once your driver is upstream,
random people won't come up with patches that break it for you.

> > > I suppose if software doesn't work for people, no maintenance is
> > > required to meet their needs, with the ultimate goal of zero
> > > users and
> > > zero maintenance.
> >
> > That's absolutely false. You can have a broken driver, with zero
> > users,
> > and still need to put a lot of maintenance work.
> >
> > Then you can have a somewhat broken driver, with plenty of users,
> > that
> > doesn't require much maintenance if any. The fact that some
> > functionality is broken has nothing to see with code maintenance.
>
> My point was that if a regression breaks people's systems and they
> decide to
> just give up and use something else, then you don't have to worry
> about those
> users' needs. Keep going along that path and you won't have to worry
> about
> anyone's needs.

And what regression are we talking about?

The upstream kernel did not support HDMI, now it does support some HDMI
screens. There is no regression here.

If the upstream driver supported your LCD panel, then an update broke
support for it, that would be a regression.

You'll have to point me to the email's object, for context. I do
somewhat remember it but can't find what email thread it's from.

And how do you read these two sentences as "take it up with the
management"?

> To me, it sounded rather like someone saying that other people behave
> in a
> particular way - again, beyond any technical procedure - and although
> that
> person has it in their power to behave differently, they will just
> copy the
> dominant social behaviour. There is plenty of scope for behaving
> differently,
> as other people have demonstrated even within the constraints of the
> Linux
> kernel effort.

Well that's an entirely separate debate. But people can only work
together on such a big project if they all use the same management
practices.

You wouldn't have half your bug reports on a mailing list and the other
half on github, would you?

> And for reference, here is the text I wrote to which you were
> responding:
>
> "I am not demanding that anyone merge my code, and I have been quite
> willing
> to accommodate various demands so that everyone feels comfortable
> about any of
> my code going into the kernel, but there has to be a tangible process
> that
> leads to the objective being reached."
>
> But, of course, you prefer to frame it all as people not trying hard
> enough,
> following the dominant social culture which can be illustrated as
> follows:
>
> https://lore.kernel.org/lkml/2015031007...@phenom.ffwll.local/
>
> As to whether people did things the right way or not, to those who
> care about
> whether any given product is viable, it just shows that the culture
> and its
> processes did not work for a specific product and arguably do not
> work for the
> majority of products. That is observable fact confirmed by the very
> topic of
> the first message in this thread.

Well, that is your opinion, and you are entitled to it.

>
> [...]
>
> > Isn't that the case for us all? I'm not really using the CI20 for
> > anything. And how is that even relevant?
>
> Because you continually frame all of this as people wanting something
> for
> their own benefit. As I noted above, I don't get any real benefit
> from
> spending hours upon hours of my time trying to assist other people,
> doing work
> that I wouldn't want to do even if it were paid, only to have my
> motivations
> mischaracterised and to be given yet more of the same, with only my
> own sense
> of obligation keeping me going until a point where there is hopefully
> going to
> be a result.

You wanted me, directly or indirectly, to spend my free time to work on
stuff you wouldn't do. Whether that was your own benefit, or for the
benefit of others, or for no benefit whatsoever, is irrelevant, really.

You realize that Google and Samsung are major contributors to the Linux
kernel, do you?

>
> [...]
>
> > Care to point out the mailing list thread where the instigator of
> > this
> > project tries to get some feedback? Because I'm genuinely curious,
> > and
> > that wasn't in a personal email addressed to me.
>
> I didn't look up the mailing list thread, but here you go:
>
> https://hackaday.io/project/185645-notkia-name-change-planned/log/212603-dismissing-the-new-arch-the-evb-and-bitter-fighting-with-linux-drivers-2022-10-09

And where do you read that the author found apathy?

Where do you read apathy in my answer?
https://www.spinics.net/lists/linux-mips/msg13906.html

The discussion didn't go further because that was my only idea about
the problem, and the bug does not appear on older SoCs (I never played
with the X1000).

> And before you take offense at what you perceive as a remark directed
> at you
> personally, let me spell out that it was a remark about the culture
> and how
> well it works for those interacting with it. You can decide for
> yourself
> whether you want to defend that culture or whether you think that
> responding
> to this person's concerns might actually be beneficial to all parties
> including yourself.

I really don't see how you can put in parallel this person's problem
with the "culture" you describe.

Fine, you do you.

Hopefully we can close this discussion now, since we won't agree on a
lot of points, and I'm pretty sure we both got tired of it.

-Paul

[Paul Boddie]

On Tuesday, 17 January 2023 19:51:21 CET pcer...@gmail.com wrote:
>
> No, we went from a system that did not support HDMI, to a system that
> somewhat supports HDMI.

Users of the CI20 who have a need to upgrade, because no-one believes in the
longevity of the systems they develop any more, go from a functional 3.18
kernel to a deficient mainline kernel.

> Unless the screen advertise a range of acceptable values, which it
> doesn't (AFAIK), then there is no way to actually fix the problem, just
> ways to mitigate it by reducing the clock delta vs. the requested
> value.

The screen advertises "a range of acceptable values" for resolutions and other
things influencing the eventual pixel clock frequency using an EDID structure,
as anyone with a cursory familiarity with HDMI would know.

[...]

> Well, I gave you criticism about your LCD pixclock problem, and instead
> of trying the alternative I suggested, you keep arguing that "if the
> vendor kernel does it this way then that's how it should be done".

No, I said that the vendor kernel manages to work with the configuration it
has been given. It should be a point of concern that the mainline kernel does
not, but apparently it isn't: a win for software quality, I'm sure.

[...]

> > As to whether people did things the right way or not, to those who
> > care about
> > whether any given product is viable, it just shows that the culture
> > and its
> > processes did not work for a specific product and arguably do not
> > work for the
> > majority of products. That is observable fact confirmed by the very
> > topic of
> > the first message in this thread.
>
> Well, that is your opinion, and you are entitled to it.

I sure am. However, in this very discussion of whether a given product is
actually supported by mainline Linux a decade after it was fully supported by
a vendor kernel, whose developers were actively trying to cooperate with the
kernel developers, only to be told "redo your work, we've changed it all" and
for the clock to run down on the time they had to do just that, the observable
reality is far more aligned with my opinion. Otherwise, this discussion would
not be taking place at all.

[...]

> You wanted me, directly or indirectly, to spend my free time to work on
> stuff you wouldn't do. Whether that was your own benefit, or for the
> benefit of others, or for no benefit whatsoever, is irrelevant, really.

There you go again.

[...]

> You realize that Google and Samsung are major contributors to the Linux
> kernel, do you?

You do realise that Google and Samsung get products to market by focusing on
delivering products and maintaining their own forks in order to be able to do
so.

[...]

> > I didn't look up the mailing list thread, but here you go:
> >
> > https://hackaday.io/project/185645-notkia-name-change-planned/log/212603-d
> > ismissing-the-new-arch-the-evb-and-bitter-fighting-with-linux-drivers-2022
> > -10-09
> And where do you read that the author found apathy?

"And sadly, no one seems to be interested in this topic. I'm on my own."

> Where do you read apathy in my answer?
> https://www.spinics.net/lists/linux-mips/msg13906.html

I did say that it was not about you personally (see below), difficult as that
might be to believe, nor that I had even read any mailing list traffic (see
above).

> > And before you take offense at what you perceive as a remark directed
> > at you personally, let me spell out that it was a remark about the culture
> > and how well it works for those interacting with it. You can decide for
> > yourself whether you want to defend that culture or whether you think that
> > responding to this person's concerns might actually be beneficial to all
> > parties including yourself.
>
> I really don't see how you can put in parallel this person's problem
> with the "culture" you describe.

So you don't see a problem with someone spending considerable effort designing
and making a product that they cannot deliver because they cannot make the
software work? Everyone is doing their own thing, I guess, and I suppose the
person concerned should have done their research and looked for a better
platform to use. Now they know better, I imagine.

[...]

> Hopefully we can close this discussion now, since we won't agree on a
> lot of points, and I'm pretty sure we both got tired of it.

I know that I have found it tiresome, certainly.

Paul

[Christophe Branchereau]

Your personal grudge is not helpful in any way to op's question, nor to anyone.

Clearly the jz4770 platform is in much better shape because there has been a huge effort to reverse-engineer the GPU that is complete, and since it's actively used in many gaming handhelds the dev is active. It's therefore a much better one for gaming dev currently.

I agree that one sometimes must swallow his pride when upstreaming, and it can be laborious to make as many revisions as requested but in the end it's for the greater good and it's working as intended.

If not happy or not wanting to bother, forking exists.

KR

[Paul Boddie]

On Wednesday, 18 January 2023 00:00:42 CET Christophe Branchereau wrote:
> Your personal grudge is not helpful in any way to op's question, nor to
> anyone.

I already replied to the original question, but one aspect of my response was
not acceptable to someone else, leading to this extended discussion. Thank you
for weighing in with your observations, though.

Paul

[Arkadi Shishlov]

Thanks to a generous donation from Graham Whaley, I now have CI20 v1 board working on my table, yay!

Upgraded NAND rootfs in-place to mipsel Debian 10 Buster (oldstable) with Mesa GL 13.0 and Wayland shims from Debian 9 Stretch (oldoldstable), Xorg server binary from Debian 8 Jessie. And it works with the original SGX OpenGL userland and CI20_Linux 3.18.3 kernel, which I rebuilt with a GCC 7.5 crosstool-ng generated toolchain. That was an experience! I guess, that's the best Linux MIPS desktop-like setup possible in 2023.

OpenGL LZDoom run 720p in window at reasonable 25-35 fps. Software-render Crispy Doom - not so well at 15-20 fps. Fullscreen programs struggle with 1080p resolution. Not enough memory bandwidth? Theoretically, 32-bit DDR3 @400/100MHz is 3.2GBps yet RAMSMP benchmark is ~400MB/sec (with HDMI enabled).

Looking forward to Buildroot with mainline Linux 6.1.8 and OpenDingoox jz-6.1 branch. What peripheral works? MMC, NAND, serial console - also in U-Boot, HDMI 1080p, some sort of Wi-Fi happening but not really, no USB so far, no SMP (as expected).