diff --git a/content/blog/figure2/index.md b/content/blog/figure2/index.md index a02fbbb..63adb48 100644 --- a/content/blog/figure2/index.md +++ b/content/blog/figure2/index.md @@ -13,11 +13,11 @@ series: Today we're reviewing the Flare reissue of the YoRHa No. 2 Type B released by Square Enix, a company that despite being very, very controlling of their merchandise has the absolute worst online store ever. This isn't just a single case, you can read online where people have similar experiences with Square Enix's online store. -## The Buying Process +### The Buying Process Buying through the (USA) Square Enix store is usually more expensive than what you can find elsewhere, and they take **forever to ship**. Not only this, but coincidentally, **the day after I received the figure** - a _better_, and _cheaper_ (overall) one showed up in the preorder listings on AmiAmi. Excuse me? Better as in this is the normally-$220-deluxe version. For **$129.** Of course, I'm picking that up! Despite the price tag difference, and a couple of accessories the two figures are virtually the same, so I'll be using them interchangeably between photos. -## The Figure +### The Figure Despite the horrendous ordering process, the figure itself is very well put together! Starting with the base, which is has a transparent, mirror-like appearance like in this photograph provided on the box: diff --git a/content/blog/fixing-22r/index.md b/content/blog/fixing-22r/index.md index 39625a4..0d8590c 100644 --- a/content/blog/fixing-22r/index.md +++ b/content/blog/fixing-22r/index.md @@ -13,10 +13,9 @@ So I bought an art tablet this year, the XP-Pen Artist 22R Pro which comes with ![My dirty, dusty 22R tablet.](tablet.webp) - While almost every part of the tablet works, only one of the two stylus buttons is functional. One button is middle mouse click, and the other one is right mouse click. For some reason, only the first stylus button works! This is obviously troublesome, so where do we begin to fix this issue? Let me take you on a journey, if you have no experience with how input works on Linux - well that makes two of us! -## Figuring Out The Problem +### Figuring Out The Problem I work in Krita, so the first place to check is Krita's tablet testing tool first. Looking at the log yields us something like this: @@ -142,7 +141,7 @@ As you can see, whenever I press the first stylus button it reports `BTN_STYLUS` Now before we go further, I just wanted to confirm whether or not the pen _actually worked at all_ so I booted up Windows real quick to test. And it does work as expected, darn. -## Going Deeper +### Going Deeper Now it's easy to assume libinput is the culprit and the one to be fixed, [like I did](https://gitlab.freedesktop.org/libinput/libinput/-/issues/842). At first, I wrote up a quick patch to remap the wrong `BTN_TOUCH` inputs and inject proper `BTN_STYLUS2` events but honestly that's dirty. So what is beneath libinput? **evdev**! @@ -184,7 +183,7 @@ It looks like the "usbhid" driver which makes sense, this is a USB HID device af So what is the proper HID driver for this device? Well after some research it turns out to be **uclogic** which handles a bunch of UGTablet, Huion and other misc Asian tablet devices. Unfortunately, they haven't added any support for this model but someone has. -## Digimend Project +### Digimend Project Luckily there is a project dedicated to upstreaming device drivers for these tablets, and Aren Villanuvea (also known as "kurikaesu") known for userspace-tablet-driver-daemon has [reverse engineered the tablet already](https://github.com/kurikaesu/DIGImend-research/blob/main/xp-pen-22r-pro.md). Better yet, he even implemented **most of the work in uclogic already**! You can see the [PR here](https://github.com/DIGImend/digimend-kernel-drivers/pull/557/). @@ -192,7 +191,7 @@ Now that's where the story ends, yay - except that my device still doesn't work. The daemon is nice and all, but I would prefer kernel support for this device for numerous reasons. And what's worse is that it's _so close_ to being complete that it sucks that the work hasn't continued. Oh well... -## Kernel Hacking +### Kernel Hacking So now I'm **trying to upstream the uclogic patch!** Oh how I wish it was a bug in a higher layer... I'll be taking over Aren's work and trying to clean up the patch and reduce it down to just supporting the 22R Pro, since that's the only tablet I own. Here's what works: diff --git a/content/blog/fixing-22r2/index.md b/content/blog/fixing-22r2/index.md index 9e89cbb..a7eae63 100644 --- a/content/blog/fixing-22r2/index.md +++ b/content/blog/fixing-22r2/index.md @@ -11,7 +11,7 @@ tags: Some more progress has been made on fixing my newest drawing tablet! -## Fixing up the patch +### Fixing up the patch So as described in the [original post]({{< ref "fixing-22r" >}}), I have to patch the uclogic HID driver. Let's start by going through the process of submitting a @@ -170,7 +170,7 @@ think my tablet pad is a... tablet pad? Okay, that's interesting - why is this a mouse? Uh oh, don't tell me... -## Fixing udev +### Fixing udev So unfortunately before my tablet is fully functional, we have to touch _another_ piece of critical Linux infrastructure - _great_. I want to dive into how libinput @@ -301,7 +301,7 @@ hardware database, as this turns out to be a udev bug. So I made [a systemd PR](https://github.com/systemd/systemd/pull/25866) fixing the logic, maybe that might fix your tablet too! -## Tilt support +### Tilt support One more thing I wanted to tackle was tilt support for the pen, which the driver says it supported but I haven't tested yet. Simple, right? (you already know the @@ -423,7 +423,7 @@ which has the unrealistic goal of complete tablet support in just one merge requ I cleaned up the relevant tilt support part, and submitted a new [merge request](https://invent.kde.org/plasma/kwin/-/merge_requests/3364) which means pen tilt/rotation is supported under KDE Wayland now! Yay! -# Dials +### Dials All is well and good now, right? That's what I thought, until I realized my **dials don't work**! I was so entrenched in everything else, that I completely neglected diff --git a/content/blog/linux-graphics-stack.md b/content/blog/linux-graphics-stack.md index 52f76d4..f394f9e 100644 --- a/content/blog/linux-graphics-stack.md +++ b/content/blog/linux-graphics-stack.md @@ -22,7 +22,7 @@ _Graphics Dump_ is a new articles series I'm starting, geared towards tutorials {{}} -## Introduction +### Introduction Since other operating systems hide these processes away from you, it is fortunate that Linux exists to easily showcase how typical desktop graphics systems function! Of course other systems like Windows, macOS, and other operating systems function differently - but a lot of the same concepts apply (API call dispatch, userspace graphics drivers, and display planes as some good examples.) @@ -30,7 +30,7 @@ However, the scope of this article has ballooned tremendously, so I had to split This article is geared towards understanding the Linux graphics stack to graphics developers like me, who primarily work with graphics APIs and sort of is confused by Mesa, DRM and other such projects. As such, I kind of hand-waive over stuff like device creation, low-level GPU functions and other terms I expect you should know already or I'm not qualified to cover. -## Vulkan +### Vulkan I don't intend to talk much about Vulkan itself here, as this is an article dedicated to the graphics stack as a whole, not just one API. However I want to clarify some misconceptions about Vulkan first. @@ -40,13 +40,13 @@ I don't intend to talk much about Vulkan itself here, as this is an article dedi With that out of the way, let's talk about how Vulkan applications typically interact with your system: -### Calling Vulkan +#### Calling Vulkan Let's say we have a very simple Vulkan program, all it does is open a window and draw a triangle. The reason why I chose Vulkan as the graphics API for this article is because it is so involved: you need to create a device, create shader pipelines, render passes and submit draw calls and perform explicit presentation sync. Vulkan's explicit swapchain management and synchronization makes it much easier to show what happens for the purpose of these articles. OpenGL and other API hide that information from you. When we call something like `vkCreatePipeline` (a call that bundles some draw information with one or more shaders) the first library you will encounter is the _"Vulkan Loader"_, not any graphics driver. The Vulkan Loader is an independent project not related to Linux graphics at all. -### Vulkan Loader +#### Vulkan Loader The Vulkan Loader does a lot more than wrap Vulkan calls, but the one that is relevant to us is that handling ICDs. "ICD" stands for _"Installable Client Driver"_, this is the actual graphics driver. @@ -66,7 +66,7 @@ On Linux, the Vulkan Loader is installed as `libvulkan.so`, but let's dig a litt ICDs are defined in plain JSON and we can find the driver library in `library_path`. We're focusing on AMD hardware in this article, but you can apply the same processes to Intel hardware and any other Mesa-supported driver. -### Inside of an ICD +#### Inside of an ICD Let's start by running `objdump` on our driver, so we can get a complete list of functions: @@ -91,7 +91,7 @@ However, if you haven't noticed already - there is functionally no difference be The answer is simple, it just calls all of them! When you call a Vulkan function through the Vulkan Loader system, if it's a device-level call it simply passes it down to the driver that the device belongs to - but if it's an instance-level function, it actually "aggregates" the data from the relevant drivers. This is what is called the "Loader Terminator". -### How the Loader Terminator Works +#### How the Loader Terminator Works A good example to showcase this is `vkEnumeratePhysicalDevices`, and as the name implies, gives you a list of the physical devices on the machine. If you have a Intel integrated GPU and say, a NVIDIA GPU, this is what the loader terminator might do: @@ -102,7 +102,7 @@ A good example to showcase this is `vkEnumeratePhysicalDevices`, and as the name This is actually a really smart design, since it would be near-useless if `vkEnumeratePhysicalDevices` only listed devices from _one_ ICD. And then once you create the logical device from that ICD's physical device, the Loader takes care of figuring out which ICD you actually want to talk to without you even realizing it. The fact that I didn't even know what a "loader terminator" was or that it even did this in the first place is a testament to how nicely this system functions. -### Overview +#### Overview That was a _lot_ of information to parse, so let me give a quick overview of how Vulkan calls eventually each your graphics driver: @@ -113,7 +113,7 @@ That was a _lot_ of information to parse, so let me give a quick overview of how This is of course assuming there are no layers activated (which are simply other programs that can intercept Vulkan calls) which may change the route your call makes. Now let's take a look at what your graphics driver actually is, and it's more complex than you might think. -## Mesa +### Mesa Mesa is the next piece of software in this call stack (the ICD). It does most of the heavy lifting here, and is an important piece of the Linux graphics stack. However, I've seen people confused on _what_ Mesa is - so let's take a look at their [website](https://mesa3d.org): @@ -142,7 +142,7 @@ that sits on top of that kernel layer and interacts with applications. Mesa impl Let's take a look at how Mesa is structured, and how they can reuse code between many devices and drivers. This will also explain the curious structure of the `objdump` from earlier, and what the `radv` prefix is referring to. -### Mesa Drivers +#### Mesa Drivers Mesa comes with many drivers, and each driver has a name (`radv`, `iris`, etc) which is unique even across different APIs: @@ -154,7 +154,7 @@ Mesa comes with many drivers, and each driver has a name (`radv`, `iris`, etc) w However Mesa has a _lot_ of drivers, and you might think it become unmaintainable - I mean supporting one graphics API is trouble enough, but Mesa somehow supports all of these drivers and all of these APIs? How do they accomplish such a feat? -### Gallium +#### Gallium Let's take a look at how their OpenGL support works first, which is easier to explain. This is so incredibly fascinating because for the longest time - whenever I think of "Gallium", and other people probably relate - I think of [Gallium Nine](https://docs.mesa3d.org/gallium-nine.html) which is the way to run DX9 almost natively on your system via Mesa. However, Gallium Nine is simply another frontend to Gallium. @@ -163,7 +163,7 @@ Gallium is a framework to reduce the amount of driver code needed to write OpenG However you might be wondering how Mesa structures it's installed OpenGL drivers. Mesa provides `libGL.so` which plays a similar role to `libvulkan.so`, and selects the correct OpenGL driver at runtime[^5]. -### Vulkan +#### Vulkan Now unfortunately Mesa doesn't have a fancy name for its Vulkan driver framework (as far as I know!) because this is mostly a new development. Previously, a lot of Mesa's Vulkan drivers implemented a whole of duplicate Vulkan work (like in instance-level functions, but also a lot of queue-related things) which wasn't a huge deal, but now that Mesa has way more Vulkan drivers (they have RADV, ANV, and soon NVK - and that's not all of them!) the work was piling up and implementations started to drift apart. Apparently a lot of RADV and subsequent Vulkan drivers were based off of ANV, and then common Vulkan code got lifted outside of the drivers later. As Jason Ekstrand says in ["Introducing NVK"](https://www.collabora.com/news-and-blog/news-and-events/introducing-nvk.html): @@ -173,13 +173,13 @@ As we've seen though, the RADV ICD simply contains _both_ the common Vulkan code Now that we covered how Mesa separates and abstracts drivers for Vulkan and OpenGL, how do the device drivers actually function? Well depending on the structure of the hardware and its unique quirks, a lot of care has to go into optimizing the API the driver is handling. But how does it actually _interact_ with the hardware? -## DRI +### DRI The answer is not so simple. You may have heard terms like DRI, DRM, KMS, DRM KMS and other things but these aren't very well explained. Mesa uses something called DRI. DRI stands for _"Direct Rendering Infrastructure"_ and is something specific to Linux. The DRI is an umbrella term also covering _DRM_ and _DRM KMS_. -### DRM +#### DRM DRM stands for _"Direct Rendering Manager"_ and refers to the DRM system that exists in the kernel. This is what the AMDGPU kernel module implements, and consequently how Mesa is able to interface with the GPU at all. It basically creates an API for userspace applications to access your GPU. The kernel module handles facilitating I/O, loading firmware and other low level things. To find the in-tree DRM kernel modules, see `drivers/gpu/drm`. @@ -195,17 +195,17 @@ Jackpot! What is this `libdrm` it mentions? It actually is specifically referrin So, the Mesa drivers doesn't interface with the kernel directly, but rather access all the device-specific functionality _through_ libdrm. This is because kernel interfaces are not truly stable and the interface isn't really meant for application consumption anyway, libdrm handles all of that for Mesa. This is also might be why Mesa doesn't define a specific kernel requirement, because it technically doesn't depend on their DRM interface. -### DRM KMS +#### DRM KMS The other major part of the DRI project is "DRM KMS", one part we now know is "Direct Rendering Manager" but what is "KMS"? It stands for "Kernel Mode Setting" and is used on modern Linux systems to initialize and configure the framebuffer. You might think that "DRM KMS" stands for a type of "KMS" but really it can't exist _without_ using DRM. You'll also sometimes see it written as "DRM/KMS" which is weird but I guess it's typical in the Linux world (like GNU/Linux.) Modesetting refers to initializing the display, handling EDIDs and all of that fun stuff. "KMS" is then referring to doing this in the kernel instead of in user space. You might be thinking that meant that user space was initializing the GPU's connected screen and you'll be right, which was slow especially when switching to things like the TTY (which is handled by the kernel) since it had no idea what the user space was doing. -### Quick Note about DRI versions +#### Quick Note about DRI versions You may have noticed this already, but there are things called DRI1, DRI2, DRI3. There are actually three different versions of DRI, which has evolved as the needs of graphics drivers and desktop compositors changed. We're currently on DRI3 and that's what I'll be covering once we get into presentation and synchronization. -## Conclusion +### Conclusion I hope this gives you a nice overview of what libraries are involved when dealing with Linux graphics, and an explanation of some of the terms you might have seen before. As stated in the beginning, this has grew and grew in scope so I'm cutting the article here so I can get it published first. @@ -213,7 +213,7 @@ In the next part we'll be covering how windowing, synchronization and presentati I'm not a Mesa nor an AMD developer, so if you see any mistakes feel free to contact me! Otherwise please enjoy and make sure to check out these other fine webpages below. -## See Also +### See Also * [Mesa Documentation](https://docs.mesa3d.org/index.html) * [Mesa Source Code](https://gitlab.freedesktop.org/mesa/mesa) diff --git a/content/blog/opening-addresses/index.md b/content/blog/opening-addresses/index.md index a1318f8..8802b96 100644 --- a/content/blog/opening-addresses/index.md +++ b/content/blog/opening-addresses/index.md @@ -40,7 +40,7 @@ print(p.format(deg_char='°', min_char='\'', sec_char='')) 3. Then, simply click an address in KAddressBook, and it'll open up in KDE Marble! -## More Details +### More Details This is actually quite interesting, as I would think KAddressBook would have this functionality out of the box, however it is more work than you might think it is. First, KAddressBook stores the address of your contacts literally, like a string - it stores the Address, Region, and Location separately (this is the `%s`, `%l`, `%r` variables as shown above). However, KDE Marble only accepts longitude and latitude as command line arguments. diff --git a/content/blog/thoughts-and-tips-on-mastodon/index.md b/content/blog/thoughts-and-tips-on-mastodon/index.md index 8ec5845..e39790b 100644 --- a/content/blog/thoughts-and-tips-on-mastodon/index.md +++ b/content/blog/thoughts-and-tips-on-mastodon/index.md @@ -14,7 +14,7 @@ Seeing the "collapse" of Twitter (although that's overstated) means a lot more p The focus isn't what's going wrong with Twitter right now, but trying to clear up some common misconceptions about Mastodon and the Fediverse in general, following questions I've seen in the relevant Knockout thread. -## Mastodon is siloed, and general server moderation thoughts +### Mastodon is siloed, and general server moderation thoughts A lot of people are naturally worried about the state of server ownership in the Fediverse world, and "siloing". To put it simply, people don't trust server owners and they are generally worried about how some servers are blocked. A lot of people tend to go for the "email" approach to @@ -29,7 +29,7 @@ people don't really know what to expect when you say "Fediverse servers work lik This is **why I think Mastodon wins**: If you don't have access to Twitter, there is basically no other way to interoperate with it. If your Mastodon server gets theoretically blocked, whatever - just import your following list (or if your server is still accessible, transfer your followers too - a native feature of Mastodon) and keep going on with your day. Bookmarks, block lists, and other similar data can be imported as shown above. In most cases though, servers are blocked for a good reason (white supremacists, nazis, loli and other content usually make up most block lists). Most of the time the good of the server system outweights the negatives, and again if you ever feel like you don't fit in with your server - you can always move and take most of your things with you! -## Should I run my own server? Is it worth it? +### Should I run my own server? Is it worth it? I summarized this point in some random thread on Knockout, but wanted to explain it better here. In most cases, which is strange - I recommend not doing so. Here's why: @@ -45,7 +45,7 @@ Also as a single user Mastodon instance, it's going to be really hard to get goi Mastodon in general is designed (perhaps intentionally or not) for communities to form around multiple servers, and something like a single-user Mastodon instance is niche, and nigh unusable (in my opinion, as someone who has tried to run one before). In this way, it actually differs from hosting your own email. -## Other nice things to know +### Other nice things to know Here's some smaller Mastodon features that I think are neat: diff --git a/content/blog/why-you-need-a-gallery.md b/content/blog/why-you-need-a-gallery.md index 23fe16a..5210cd8 100644 --- a/content/blog/why-you-need-a-gallery.md +++ b/content/blog/why-you-need-a-gallery.md @@ -21,23 +21,23 @@ This is the crux of the issue - many of these websites fizzle out after a decade However the problem is that artists _depend_ on them too much, and they especially build _their identity_ around them. How many artists are sticking to Twitter because thats where they get the most likes? What will happen if Twitter _does_ disappear by the end of the year[^3]? What I suggest to artists is simple: **build your own website.** -## Is it too expensive? +### Is it too expensive? **NO!** This is probably the biggest hurdle for most artists to understand, that hosting a website can either be very cheap or completely free. There are lots of drag-and-drop website builders[^4], but if you're more technically minded there are very cheap servers available from reputable providers to host something like [WordPress](https://wordpress.org) or even build a website in something like [Hugo](https://gohugo.io) (hi!) However one of the more expensive costs is a _domain name_[^5], which is a fancy TLD like `myart.com` instead of your hosting provider like `myart.wordpress.com`. I highly suggest buying a domain name if you have an alias, but this is optional - what's important is that you're hosting your content on your terms and a domain name is just one part of strengthening your identity. -## Is it hard? +### Is it hard? **NO!** Depending on how complex you want to be, it can be tough but for most people their site builder ([Wix](https://www.wix.com), [WordPress.com](https://wordpress.com), etc) will allow them to easily create galleries, link their social media and so on. Even a blank white website with a list of your social media will work. In my opinion, if you're capable of drawing, making music, pottery or another profession in the first place, then you're perfectly capable of displaying the same passion on a website - it's another skill! -## What's difference between X (Tumblr, Twitter, Newgrounds)? +### What's difference between X (Tumblr, Twitter, Newgrounds)? When you choose to host your own website, **you** choose to present your content on your own terms[^6]. There are no _"Site Admins"_, there are no _"Shareholders"_ seeking to remove yet another customization choice from your profile. If Twitter shuts down tomorrow, Pixiv decides to crack down on R-18, or some other major event - you know what you can do? Sit back and enjoy that you're part of the independent web. You don't need to abandon Twitter, but realize that you should get a backup plan. -## Backups +### Backups Here's just a small thing partially related to the topic of this article, **please keep backups**! I have (most) of my art backed up since 2016, and every time I access my archive I'm thanking myself over and over. Even if it's some bad sketch or music demo, I highly suggest keeping the source file and/or a rendered copy of it. Make sure to keep a copy on your website but also off-line as well, in case your hosting provider goes off-line or you lose access in some way. @@ -52,4 +52,4 @@ site builder like building a Tumblr theme - it actually works quite well and doe [^5]: The cost depends on the TLD you choose, but they typically are within $10-15 USD a year. Some domain registrars are run deals so it might even be cheaper. However, due to ICANN rules you **are** required to provide valid, legal contact information such as your real name, address and other sensitive information. Assuming your registrar provides WHOIS protection (which they typically do), this information is **not** public to anyone except for the registrar, but keep this in mind before buying a domain. -[^6]: Of course, you have to listen to ICANN, your country's internet policing agency and your hosting provider - but you also have to do the same with any social media website. You just cut out more middlemen! \ No newline at end of file +[^6]: Of course, you have to listen to ICANN, your country's internet policing agency and your hosting provider - but you also have to do the same with any social media website. You just cut out more middlemen!