Re: X11 vs Wayland: KiCAD story.
On Wed, Jun 18, 2025 at 3:19 PM Nathan Hartman wrote: > On Wed, Jun 18, 2025 at 8:48 AM Tomek CEDRO wrote: > > > https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ > > > > Looks like (self-)compatibility problem of enforced changes solutions > > is arising in the Open-Source world and statements are made in more > > and more projects :-) > > Yeah, don't even get me started! > > I agree with what you've said on many occasions about the importance of > stability! Changes that really improve things are good. Changes for > changes' sake... not so much. > > BTW, I use KiCad. On the downloads page for Linux/Other [1], you can see > which version of KiCad is available for several distributions. Until very > recently I was disappointed to see that only an ancient version (7 point > something) was available for FreeBSD, but lately that has improved and now > the very latest (9.0.2 at this writing) is available on FreeBSD! Yes it is available for a long long time since 2005 (see https://www.freshports.org/cad/kicad/), however, on many bug occasions I heard its not supported platform so we are on our own, but the ideas and fixes wen to the upstream with no problem :-) > Currently I use it on Debian, but if Debian ever goes Wayland-only, I may > have to switch to FreeBSD, in the hopes that they won't eliminate good ol' > X11 You are always welcome to the FreeBSD world Nathan :-) You can even debootsrap Debian here and use all of its applications (well except those that are hard tied to Linux kernel or weird sysctls) :D I use Debian12 for stuff that does not work otherwise (i.e. 3d slicer or other linux only binary apps) and to verify cross-platform stuff :-) % uname -a FreeBSD hexagon 14.2-RELEASE-p3 FreeBSD 14.2-RELEASE-p3 #0 releng/14.2-n269524-1eb03b059e56-dirty: Sun Jun 15 04:00:07 CEST 2025 root@hexagon:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 % pkg info kicad kicad-9.0.2_1,2 % chroot -n /compat/debian12 /bin/bash cederom@hexagon:/$ uname -a Linux hexagon 5.15.0 FreeBSD 14.2-RELEASE-p3 #0 releng/14.2-n269524-1eb03b059e56-dirt x86_64 GNU/Linux cederom@hexagon:/$ apt show kicad Package: kicad Version: 6.0.11+dfsg-1 You can use whatever you like here, there are no enforced changes but choice, either Xorg or Wayland or both work and these are provided as userland packages (i.e. pkg install xorg). FreeBSD is configured with simple plaintext /etc/rc.conf, has common minimal OS Base (all users, workstations, and over the years) in / where you start, then you have Userland in /usr/local where users can do whatever they like (including /usr/local/home). This comes from historical setups where base was booted over pxe and userland was attched over nfs so you can work on disk-less terminals :-) There is pkg package manager and all userland applications are built with "port" that is single Makefile for each port automating the fetch extract optional patch build and package creation. The mindset and approach is similar to NuttX, even the organization i.e. base = nuttx.git and ports = nuttx-apps.git :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
X11 vs Wayland: KiCAD story.
https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ Looks like (self-)compatibility problem of enforced changes solutions is arising in the Open-Source world and statements are made in more and more projects :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: X11 vs Wayland: KiCAD story.
On Wed, Jun 18, 2025 at 8:48 AM Tomek CEDRO wrote: > https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ > > Looks like (self-)compatibility problem of enforced changes solutions > is arising in the Open-Source world and statements are made in more > and more projects :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > Yeah, don't even get me started! I agree with what you've said on many occasions about the importance of stability! Changes that really improve things are good. Changes for changes' sake... not so much. BTW, I use KiCad. On the downloads page for Linux/Other [1], you can see which version of KiCad is available for several distributions. Until very recently I was disappointed to see that only an ancient version (7 point something) was available for FreeBSD, but lately that has improved and now the very latest (9.0.2 at this writing) is available on FreeBSD! Currently I use it on Debian, but if Debian ever goes Wayland-only, I may have to switch to FreeBSD, in the hopes that they won't eliminate good ol' X11 Oh, the above KiCad/Wayland thing was discussed on HN [2]. There are varying opinions about this... [1] https://www.kicad.org/download/linux/ [2] https://news.ycombinator.com/item?id=44297381
Re: Sv: Sv: Sv: RFC: fix race conditions in drivers/serial/serial.c
Hello, finally got to it, 4th revision of the patches is in branch named uart_fixes_rfc4 and also attached. This revision incorporates suggestions from GitHub review. 1. The order of patches in the series is reversed (not counting the typo fix patch.) The less intrusive one is now placed before the other. This way, the smaller fix is not affected by changes that follow, namely by using the new data type. 2. Instead of ifdefs in various places, the patch introduces type sbuf_size_t in include/nuttx/serial/serial.h . Buffer size, head and tail variables are changed to this type. 3. ARCH_LD_16BIT_NOT_ATOMIC configuration option is renamed to ARCH_LDST_16BIT_NOT_ATOMIC to denote that store operations are not atomic as well for the architecture. 4. Default serial buffer size is changed from 256 to 252. Additionally, help of configuration options for USARTn_(RX|TX)BUFSIZE now mentions that if the architecture is unable to load/store 16-bit values atomically, the size of buffer is stored in uint8_t. 5. New configuration option ARCH_HAVE_SERIAL_8BIT_BUFSIZE is added. This configuration option triggers change of sbuf_size_t from default int16_t to architecture-specific uint8_t. It is, however, not selected from AVR serial driver Kconfig option as the review suggests. Instead, it is selected by ARCH_LDST_16BIT_NOT_ATOMIC. The reasoning for doing it this way is that AVR is (likely) not the only architecture suffering from this race condition - any 8-bit architecture is, unless it does 16-bit loads/stores atomically. As far as I was able to find, this applies to Z80 as well. Also, serial buffer is likely not the only area that introduces such a race. If more such cases are found, selecting all configuration options that enable measures that prevent these race conditions from all affected architectures would lead to M x N configuration options and all architectures would need to track new options being added. Selecting all of them from single point (ie. from ARCH_LDST_16BIT_NOT_ATOMIC) makes the configuration easier, the architecture only needs to declare what is is (in)capable of and all related options will be enabled automatically. As for the comment from jlaitine - I also find it strange that the original index is a signed value and I found no reason for it being that way. And yes, it is left untouched to prevent any changes in other architectures. If there is still something left to improve, let me know. Thanks. On 2025-06-11 13:42, alin.jerpe...@sony.com wrote: Hi KR, I added your comments Best regards Alin Från: kr@kerogit.eu Skickat: den 11 juni 2025 07:54 Till: dev@nuttx.apache.org Ämne: Re: Sv: Sv: RFC: fix race conditions in drivers/serial/serial.c Hello, thanks. Here is a response to xiaoxiang781216's review: > could we extract a common typedef to avoid #ifdef/#else/#endif spread > the code base? Can do - sbuf_size_t seems unused throughout the whole tree so I'll add that to serial. h. Hello, thanks. Here is a response to xiaoxiang781216's review: could we extract a common typedef to avoid #ifdef/#else/#endif spread the code base? Can do - sbuf_size_t seems unused throughout the whole tree so I'll add that to serial.h. can we change to ARCH_HAVE_8BIT_BUFSIZE and put into serial/Kconfig? I am not sure if that means to a) change the name from ARCH_LD_16BIT_NOT_ATOMIC to ARCH_HAVE_8BIT_BUFSIZE or b) add ARCH_HAVE_8BIT_BUFSIZE and have it selected by ARCH_LD_16BIT_NOT_ATOMIC? Neither seems fully correct though. The first variant reduces the problem to buffers only but that is too narrow. Essentially, any other value that is simultaneously written in interrupt code and read in non-interrupt code needs the be treated in the same manner as buffer head/tail here. The current name reflects that. Also, adding ARCH_LD_32BIT_NOT_ATOMIC may be needed as well (possibly not only for AVR but for 16 bit microcontrollers too - if I understand it correctly, that applies to Freescale M9S12.) The second variant implies that all of the arch has 8 bit buffer size for all buffers everywhere which is not true and may not be desirable. How about adding ARCH_HAVE_8BIT_SERIAL_BUFSIZE to serial/Kconfig and have it selected by ARCH_LD_16BIT_NOT_ATOMIC? could we directly change the default value to 255 Can be done but that would affect other architectures as well which is something I wanted to avoid. Also, using 255 feels dangerous when the underlying type is uint8_t. Might lead to bugs where expression like (x + 1 > size) never evaluates to true. Not that I see any such code in current sources, but if the default value should change for all architectures, I would rather use 252 out of abundance of caution. move to help of ARCH_LD_16BIT_NOT_ATOMIC I think it would be better to put something more generic in there. Additionally, I'll copy the comment about the buffer size to help for USARTn_RX/TXBUFSIZE. why not merge
X11 vs Wayland: KiCAD story.
Hi Tomek, Xorg also is getting forked, BTW a nice article: https://www.dedoimedo.com/computers/xlibre.html I truly believe that the idea of Wayland created by Kristian Høgsberg was to fix many issues existing in X11. But of course, just like PulseAudio and Systemd from Lennart Poettering, this project has a lot of controversies and people who don't like the changes. Recently re-reading the "Advanced Programming in the UNIX ® Environment" Third Edition (nice book for anyone willing to use NuttX) I saw this comment from Dennis Ritchie: "Unix was able to adapt rather gracefully to a networked environment and, perhaps less elegantly, but still adequately, to a graphical one." Anyway, Wayland had almost 17 years to have the basic features existent on X and to implement a more adequate solution. Unfortunately it didn't happen. BR, Alan On Wed, Jun 18, 2025 at 9:48 AM Tomek CEDRO wrote: > https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ > > Looks like (self-)compatibility problem of enforced changes solutions > is arising in the Open-Source world and statements are made in more > and more projects :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: Sensor fusion on NuttX
Thank you for the explanation! That sounds like a good plan. Please ping me (@linguini1) on the PR when you open it for visibility. In the meantime, I'll brainstorm what the best method of creating a fusion library might be. I want the user to choose themselves whether a thread is spawned to asynchronously perform fusion or if they want to do it synchronously, so I'll have to come up with some kind of standard way to generate fused data with function calls. Thanks again, Matteo On Wed, Jun 18, 2025 at 12:04 AM 董九柱 wrote: > Hi Matteo Golin： > > I see under `uorb/sensors` there are > > lots of header and C files that just contain declarations for uORB types, > > but these declarations already exist in the kernel. Why are they > duplicated > > in nuttx-apps? > > > 1.We define all the uORB-related metadata for physical sensors under the > directory nuttx-apps/system/uorb/sensor(by using ORB macro > function:ORB_DEFINE、ORB_DECLARE). This metadata primarily describes the > name of each topic, the size of its associated structure, and debug > callback functions. > And the structure definitions for these topics are placed in > nuttx/include/nuttx/uorb.h, allowing kernel drivers to utilize them > directly. > > 2. When we want to use a specific topic, such as the accelerometer topic, > we simply need to include in our application and then use > APIs like orb_subscribe to subscribe to it. However, this assumes that the > accelerometer driver is functioning correctly. > > The main reason for separating them is that uORB is a user-layer SDK and is > not utilized by the kernel. However, the structure definitions are required > by both the kernel and user-space applications. Hence, they are placed > within the kernel. > > Can anyone shine some light on why the `uorb/sensor` declarations are > > necessary, and if it would be possible for me to create user space fusion > > drivers in `uorb/fusion` with their own Kconfig file? > > > Previously, xiangxiao suggested moving all sensor-related components to > the *apps/sensor* directory. So, We could create a separate > *apps/sensor/fusion/* directory under it, and within the fusion directory, > we could establish our own Kconfig file. This fusion directory would be at > the same level as the apps/sensor/uorb directory. > I will submit a PR to move them, and we can have discussions under that PR. > > > Matteo Golin 于2025年6月18日周三 02:34写道： > > > Hello, > > > > Was starting to work more on this today, but I'm confused about how the > > `uorb` directory is currently set up. I see under `uorb/sensors` there > are > > lots of header and C files that just contain declarations for uORB types, > > but these declarations already exist in the kernel. Why are they > duplicated > > in nuttx-apps? > > > > I was hoping to create a "fusion library", with userspace implementations > > of uORB drivers using `usensor`. Something where the user can include > this > > library and choose which fusion nodes they want to register in their > > application, *not* an example program that just runs and registers a > > sensor. This way the user has full control. I was thinking about putting > > this under `uorb/fusion`, but I want to include a Kconfig file so users > can > > enable/disable fusion drivers that they want to include using > `menuconfig`. > > I don't think I can put another Kconfig file in `uorb/fusion` since > there's > > already a Kconfig file in `uorb`, but I could be wrong. To me, this > > location seems like the intuitive place to put fusion libraries, but I > > don't want it conflated with the `uorb_listener` application since it's a > > user-available library. > > > > Can anyone shine some light on why the `uorb/sensor` declarations are > > necessary, and if it would be possible for me to create user space fusion > > drivers in `uorb/fusion` with their own Kconfig file? > > > > Matteo > > > > On Fri, Jan 31, 2025 at 5:52 PM Tomek CEDRO wrote: > > > > > On Fri, Jan 31, 2025 at 10:56 PM Matteo Golin > > > wrote: > > > > Given the discourse around breakages in synchronization between the > > > > nuttx-apps and nuttx repositories, I think I may begin adding new > > > > applications to `apps/sensors` but I will hold off on moving any > > already > > > > existing sensor examples. In the coming days I expect to have > something > > > > functional for determining altitude from barometer data. > > > > > > Looks like someone missed something, or we didn't catch the problem on > > > time with PR/CI, its clearly a bug not by design, but it seems easier > > > to write emails than send actual patches :-) > > > > > > Keep your repos in sync, fear not, share your stuff, report problems > > > when found any, have fun, if you plan to break existing stuff just > > > create a separate application so everyone is safe :-) > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > >
