3 ms·

This is more like "by communicating with the X server", which is not exactly the level of "from scratch" I was expecting, but then again, it's more involved tha

This is more like "by communicating with the X server", which is not exactly the level of "from scratch" I was expecting, but then again, it's more involved than the equivalent in Win32 that's not much more than filling in some structures and invoking a few functions.

signa11 1y ago
seesh ! what would `from scratch` mean for you ? invent the whole universe ?
- userbinator 1y ago
  I was expecting something closer to direct framebuffer writes, as is often done in the various write-an-OS articles that get posted here semi-regularly.
  - signa11 1y ago
    i on the other hand, just loved the article. was a bit confused about the segfault stuff mentioned towards the beginning of the article. but got quite quickly disabused of that notion with gdb etc.
  - chickenzzzzu 1y ago
    KMSDRM is soooo much more fun than X. Truly the way programs were meant to be.
    - sim7c00 1y ago
      and then once it works u can slap it to ur own OS and avoid the rest of linux too! yay! :')
      - chickenzzzzu 1y ago
        that is correct, id rather attempt to understand the hdmi protocol before i understand 50 million lines of linux ^.^
- sim7c00 1y ago
  no u just grab the framebuffer addr somewhere (lot of places u can dig that up) and ram in the right type of pixels. :'). this article demoes exactly 0 GUI functionality...
- theamk 1y ago
  Talk to hardware directly Most "from scratch" would be some sort of microcontroller - write directly to hardware, program registers directly. It's the best feeling when you know every single instructions on the CPU is under your control, there is no 20 million lines of kernel code that do something. But the MCU needs special hardware (MCU itself, display, programmer) so it is not a good starting project. This brings us to good old MS-DOS. Sure, you need to call BIOS to set up graphics (mode 13h, "320x200x256 colors" is the best for beginners), but after that, you are talking directly to hardware.
vidarh 1y ago
It's not even that much more involved, just tedious. The serialization/deserialization of X requests and responses is fairly straight-forward (it could be more straightforward - it's not a very nice protocol, but it's also not difficult), as the article also shows, and it can be made more compact than that with a couple of helpers. The biggest pain in doing "raw" X is the async nature of the protocol - to write a robust X client you really want an event-loop driven approach that embraces that like XCB does, instead of trying to paper over it (like Xlib did).

signa11 1y ago

seesh ! what would `from scratch` mean for you ? invent the whole universe ?

userbinator 1y ago
I was expecting something closer to direct framebuffer writes, as is often done in the various write-an-OS articles that get posted here semi-regularly.
- signa11 1y ago
  i on the other hand, just loved the article. was a bit confused about the segfault stuff mentioned towards the beginning of the article. but got quite quickly disabused of that notion with gdb etc.
- chickenzzzzu 1y ago
  KMSDRM is soooo much more fun than X. Truly the way programs were meant to be.
  - sim7c00 1y ago
    and then once it works u can slap it to ur own OS and avoid the rest of linux too! yay! :')
    - chickenzzzzu 1y ago
      that is correct, id rather attempt to understand the hdmi protocol before i understand 50 million lines of linux ^.^
sim7c00 1y ago
no u just grab the framebuffer addr somewhere (lot of places u can dig that up) and ram in the right type of pixels. :'). this article demoes exactly 0 GUI functionality...
theamk 1y ago
Talk to hardware directly Most "from scratch" would be some sort of microcontroller - write directly to hardware, program registers directly. It's the best feeling when you know every single instructions on the CPU is under your control, there is no 20 million lines of kernel code that do something. But the MCU needs special hardware (MCU itself, display, programmer) so it is not a good starting project. This brings us to good old MS-DOS. Sure, you need to call BIOS to set up graphics (mode 13h, "320x200x256 colors" is the best for beginners), but after that, you are talking directly to hardware.

vidarh 1y ago

It's not even that much more involved, just tedious. The serialization/deserialization of X requests and responses is fairly straight-forward (it could be more straightforward - it's not a very nice protocol, but it's also not difficult), as the article also shows, and it can be made more compact than that with a couple of helpers. The biggest pain in doing "raw" X is the async nature of the protocol - to write a robust X client you really want an event-loop driven approach that embraces that like XCB does, instead of trying to paper over it (like Xlib did).