Any VT100 and/or NSH Console experts?

2025-03-07 Thread Tim Hardisty
I am writing a Framebuffer console app that takes stdout and stderr and renders the text to a framebuffer device. Based on existing NXGL code and example apps. It spawns NSH, and I get the NSH prompt on my LCD - and it basically works. I have also added functions to decode the handful of VT100

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

2025-03-07 Thread Alan C. Assis
Alin, but this is not an enforced rule of Linux, see: https://github.com/torvalds/linux/commit/35fa2d88ca9481e5caf533d58b99ca259c63b2fe https://github.com/torvalds/linux/commit/6a774228e890ee04a0ee13f4e6e731ec8554b9c2 https://github.com/torvalds/linux/commit/d0caf9876a1c9f844307effb598ad1312d9e002

Re: [EXT] Re: Re: socket CAN timestamp missing

2025-03-07 Thread Javier Casas Marin
Hi Peter, I just created the PR Thanks Javier Casas MarĂ­n Geotab Senior Embedded Systems Developer Direct Toll-free Visit +34 900 535 371 www.geotab.com/es Twitter | Facebook | YouTube | L

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

2025-03-07 Thread Alin Jerpelea
Hi all, I was always looking at the kernel.org is a good development practice since it has a huge community and it has been around for some time https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/Documentation/bpf?h=v6.14-rc5 if we decide that it is too hard to split commi

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

2025-03-07 Thread raiden00pl
I also don't understand this practice of separating documentation from code. When changes in the code have to be reflected in the documentation, what's the point of splitting it into separate commits? If, for example, I do a `git revert`, it may happen that the documentation and code are out of syn

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

2025-03-07 Thread Alin Jerpelea
Hi Alan, development best practices ask for commits to be split in areas they touch Related to that PR: Documentation in not software and does not belong to code changes in arch I think that this rule should be enforced even if we don't do LTS releases for now but we will do them in the future.