@azonenberg That section was it! I changed:

#ifdef __APPLE__
io.FontGlobalScale = 1.0f / scale;
to
io.FontGlobalScale = 1.0f;
and voila, UI scale appropriately!

I have no idea how that works on other macOS versions though. I'm on 15.1, not quite latest (15.5).

@jperkin for https://reports.pkgci.org/SmartOS/upstream/trunk/20250703.2249/xdm-1.1.17/build.log in which I am the person responsible for the upstream code that's breaking - this is due to a change #illumos made to their PAM headers last year that makes them compatible with Linux PAM instead of Solaris PAM - but the current xdm upstream code just checks for #ifdef __sun - I'll have to think about how to write a better test for this in xdm.

#ifdef SUPPORT_GAME_TETRIS
TerisPolling(diff);
#endif

TERIS? FUCKING TERIS?

@eniko Or add an equivalent of #ifdef so you can have platform specific code for multiple platforms inside the same function

#ifdef Py_GIL_DISABLED
    PyMutex mutex;
#endif

Yeah, we'll remove the GIL, so the libraries can GIL themselves instead.

しかし、
https://gitlab.freedesktop.org/xorg/xserver/-/blob/8006778970fe93d8a6bbd105174faa2f58f0ffb5/xkb/xkbInit.c#L63
この #ifdef __sun というのが定義されるのは SunOS / Solaris だけ、つまり「Sunのキーボードで動くOSは SunOS だけ」みたいなダメな思想に見えるけど、 XKBが「どんなキーボードが来てもサポートする」みたいな仕様なのにこの実装の雑さはなんなの

@eri @sterophonick they just have #ifdefs for the new features

Pickingbuffer shenanigans; I can now click on things, and stuff happens! ^_^ #screenshotsaturday

I am also rather surprised that I could not find a non-messy way to have the picking stuff be separate from the normal rendering pipeline (without `#ifdef`'s everywhere); how do people do this? 😅

Increasingly convinced that using `#ifdef` switches in C++ ought to be a banishable smell for everything except interfacing with third-party APIs.

@quicheindustries Ohh, and does it work if you #ifdef out the createPDF method call on simulators without bumping the version? Not at home right now to try it out, but if it works it might be an easier solution until they solve it!

Quick analysis of Firefox Widevine support:
The checkbox in about:preferences#general
is defined in
browser/components/preferences/main.inc.xhtml, like so:

<!-- DRM Content -->
<groupbox id="drmGroup" data-category="paneGeneral" data-subcategory="drm" hidden="true">
  <label><html:h2 data-l10n-id="drm-content-header"/></label>
  <hbox align="center">
    <checkbox id="playDRMContent" preference="media.eme.enabled"
              class="tail-with-learn-more" data-l10n-id="play-drm-content" />
    <html:a is="moz-support-link"
      data-l10n-id="play-drm-content-learn-more"
      support-page="drm-content"
    />
  </hbox>
</groupbox>

And it's bound to the media.eme.enabled config.

Additionally, the CDM system has a status enum:

enum MediaKeySystemStatus {
  "available",
  "api-disabled",
  "cdm-disabled",
  "cdm-not-supported",
  "cdm-not-installed",
  "cdm-created",
};

/* Note: This dictionary and enum is only used by Gecko to convey messages
 * to chrome JS code. It is not exposed to the web.
 */
[GenerateToJSON]
dictionary RequestMediaKeySystemAccessNotification {
  required DOMString keySystem;
  required MediaKeySystemStatus status;
};

And the You must enable DRM to play some audio or video on this page. message is the locale string emeNotifications.drmContentDisabled.message2, and it's triggered in browser/actors/EncryptedMediaParent.sys.mjs when:

      case "api-disabled":
      case "cdm-disabled":
        this.handledMessages.add(status);
        notificationId = "drmContentDisabled";
        buttonCallback = () => {
          this.ensureEMEEnabled(browser, keySystem);
        };
        notificationMessage = lazy.gNavigatorBundle.GetStringFromName(
          "emeNotifications.drmContentDisabled.message2"
        );
        supportPage = "drm-content";
        break;

So if we wanna completely disable DRM support without annoying the user, we could set cdm-not-supported and blank out the checkbox.

Or, there is also the browser.eme.ui.enabled perf that's checked first, and if it's false, the whole system bails out (in browser/actors/EncryptedMediaParent.sys.mjs):

  isUiEnabled() {
    return Services.prefs.getBoolPref("browser.eme.ui.enabled");
  }

The pref is defined like so, in browser/app/profile/firefox.js:

#if defined(MOZ_WIDEVINE_EME)
  pref("browser.eme.ui.enabled", true);
#else
  pref("browser.eme.ui.enabled", false);
#endif

Additionally, MOZ_WIDEVINE_EME also sets (in browser/app/profile/firefox.js):

// Note: when media.gmp-*.visible is true, provided we're running on a
// supported platform/OS version, the corresponding CDM appears in the
// plugins list, Firefox will download the GMP/CDM if enabled, and our
// UI to re-enable EME prompts the user to re-enable EME if it's disabled
// and script requests EME. If *.visible is false, we won't show the UI
// to enable the CDM if its disabled; it's as if the keysystem is completely
// unsupported.
#ifdef MOZ_WIDEVINE_EME
  pref("media.gmp-widevinecdm.visible", true);
  pref("media.gmp-widevinecdm.enabled", true);

So you can set all three of those to false:

pref("media.gmp-widevinecdm.visible", false);
pref("media.gmp-widevinecdm.enabled", false);
perf("browser.eme.ui.enabled", false)

in a preference js file in your profile / dist.

Unsure exactly what sets MOZ_EME/MOZ_WIDEVINE_EME stuff.

According to https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42501,
and referencing toolkit/moz.configure, we have:

# EME Support
# ==============================================================
@depends(target, wmf)
def eme_choices(target, wmf):
    if (
        target.kernel in ("WINNT", "Linux")
        and target.os != "Android"
        and target.cpu in ("x86", "x86_64")
    ):
        if wmf:
            return ("widevine", "wmfcdm")
        return ("widevine",)
    if target.kernel == "WINNT" and target.cpu == "aarch64":
        return ("widevine",)
    if target.os in ("OSX"):
        return ("widevine",)


# Widevine is enabled by default in desktop browser builds.
@depends(build_project, eme_choices)
def eme_default(build_project, choices):
    if build_project == "browser":
        return choices


option(
    "--enable-eme",
    nargs="+",
    choices=eme_choices,
    default=eme_default,
    when=eme_choices,
    help="{Enable|Disable} support for Encrypted Media Extensions",
)


@depends("--enable-eme", when=eme_choices)
def eme_modules(value):
    return value


# Fallback to an empty list when eme_choices is empty, setting eme_modules to
# None.
set_config("MOZ_EME_MODULES", eme_modules | dependable([]))

TL;DR, when not building from source, can just set the three perfs:

pref("media.gmp-widevinecdm.visible", false);
pref("media.gmp-widevinecdm.enabled", false);
perf("browser.eme.ui.enabled", false)

And when building from source, can try either --disable-eme, or patching toolkit/moz.configure to return None (it's Python) (which should be the default when --disable-eme doesn't work)

(CC: @hellomiakoda)

ESP32 S3 DevKit

Having played a bit with ESP32-S3 now, in the of the Waveshare Zero format boards, I’d quite like to have a version of the ESP32 WROOM Mozzi Experimenter PCB for the latest ESP32-S3 DevKitC board I’ve found.

This is the introductory post that is my “notes to self” as I get to know the boards.

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Microcontrollers, see the Getting Started pages.

ESP32-S3 DevKitC Boards

There are a couple of ESP32-S3 official DevKits, in addition to the huge range of third party boards from the likes of Waveshare, Adafruit, and so on of course.

The main references for these boards are:

• ESP32-S3 SOC page
  • ESP32-S3 datasheet
  • ESP32-S3 WROOM-1/1U/2 modules
• ESP32-S3 DevKitC-1 – based on the WROOM modules
• ESP32-S3 DevKitM-1 – based on the Mini modules

Note: although the C and M DevKits both have 44 pins and very similar functionality, the actual pinouts for the two boards are quite different. On the face of things, it looks like the pinout for the M version seems a bit more logical to me than the C version, but I’ve ended up with C boards, so that is what I’m going with! Much of what follows is applicable to both though.

It is also worth noting that I was looking at the ESP32-S3 as a possible replacement for the original ESP32 in my Educational DIY Synth Thing. But in terms of general features, the ESP32-S3 and ESP32 are actually pretty similar.

From the comparison here, here are some key features listed:

Most of the peripherals are pretty similar too.

So the key difference is the switch from LX6 to LX7. As both support a single-precision floating point unit, and up to 240MHz operation in dual core modes, I’m not sure what the enhancement is at the moment.

One difference on Wikipedia is that the LX7 has “added instructions to accelerate machine learning applications” and it appears that there is a specific library that makes use of these instructions: ESP-DL. But I’ve not seen if any of this is likely to help me with audio.

I should also note that the original ESP32 is the only chip in the architectural family (as far as I can see) with an integrated DAC. There is certainly no DAC with the ESP32-S3.

I was determined to go with the official ESP32-S3 DevKitC board this time. But on my first attempt I managed to end up with a very close clone! I have now have two variants as shown below. The original is on the left and the clone on the right.

The clones are very similar to the original but seem to have the following differences.

Physical Differences:

• The clone is shorter and 2.54mm (i.e. a “pin row”) wider.
• Buttons are in a different place.
• USB-C ports in different place compared to the GPIO pins.

Electrical Differences:

• The USB ports are swapped. The original has UART on the left, USB on the right. The clone is swapped.
• Clone has a solder jumper on the rear for USB-OTG for the USB port. If soldered, this shorts a diode in the VBUS 5V line to allow the USB port to power an external device.
• Original has an SK68xx LED (powered from 3V3), the clone has a WS2812 (powered from 5V), although they should be essentially the same code/protocol wise.
• Original has the LED on GPIO38 (maybe – mine doesn’t). Clone has LED on GPIO48.
• Clone has a solder jumper for the LED which is connected by default.
• Original uses a CP2102N USB serial chip. Clone has a CH343P.
• Original uses a SGM2212 regulator which has a 2.7-20V input range. Clone uses a CJ6107 with range 2.5-6V. Although in both cases the input is essentially 5V from USB VBUS.
• The clone has an IN-OUT solder jumper. If soldered, this shorts a diode on header pin 21 (5V) to allow power to be fed into the board via the 5V pin.
• The clone has a RX and TX LED.
• The clone has the (strapping) pin 3 pulled HIGH to 3V with an additional 0R resistor in place in case that is not required.

Documentation for the original board: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32s3/esp32-s3-devkitc-1/user_guide.html

Documentation for the clone: https://github.com/vcc-gnd/YD-ESP32-S3/tree/main/5-public-YD-ESP32-S3-Hardware%20info

At least the pinouts for the two modules seem the same, apart from the fact that one module is one-pin-header-row wider than the other.

ESP32-S3 DevKitC-1 GPIO Use

Strapping pins are used to set the configuration of the ESP32-S3 on power up. For details of the strapping pins and their use, see Section 4 in the ESP32-S3-WROOM-1 guide. The summary, and default settings for the ESP32-S3, is as follows:

Working through the datasheets, schematics and online guides, as far as I can make out the following GPIO pins all have an expected use on the DevKitC-1 boards, which can limit their use for general projects.

Taking account of all the above, this leaves the following GPIO pins probably available for use in projects:

So this would hopefully give me access to 19 GPIO that could act as analog inputs and a further 7 GPIO in addition to two for RX/TX.

This assumes that GPIO 47 and 48 not operating with an SPI flash configuration that means they will run at 1.8V. For the modules I have I’m using a ESP32-S3-N16R8 module so this should be fine as this only applies to the N16R16VA variants of the modules.

In terms of functions, the way the ESP32-S3 supports GPIO multiplexing means that any of these could be configured for I2C or I2S, and they all support PWM outputs.

For a more detailed discussion of the restrictions, see https://github.com/atomic14/esp32-s3-pinouts

EPS32-S3 and Arduino

Serial Ports

There are several options for serial ports:

• Native USB (the “USB” USB port)
• USB via UART0 (the “COM” USB port)
• UART0 directly via TX/RX
• UART1 via GPIO

These map onto the following serial options in Arduino (see cores/esp32/HardwareSerial.h):

There is a build option that determines whether the loaded code includes a USB comms device or not.

If this isn’t set (i.e. “disabled”) then Serial goes to UART0 and the serial monitor has to be connected to the “COM” USB port.

If this is set (i.e. “enabled”) then Serial goes to USBSerial and the serial monitor can be connected to the “USB” USB port.

Note: there is some ESP32 start-up debug information that will always go to UART0 on boot regardless of this setting.

Analog Input

One quirk of the ESP32 Arduino environment and the ADC mapping means that the ADCs are mapped as follows:

• ESP32 ADC1 peripheral: channels 0 to 9 = GPIO 1 to GPIO 10 = Arduino A0 to A9
• ESP32 ADC2 peripheral: channels 0 to 9 = GPIO 11 to GPIO 20 = Arduino A10 to A19

This can be seen in the board definitions file for the Arduino ESP32 core: https://github.com/espressif/arduino-esp32/blob/master/variants/esp32s3/pins_arduino.h

Specific GPIO

We can also see the following from pins_arduino.h:

• TX/RX = GPIO 43, 44 (as might be expected).
• SDA/SCL = GPIO 8, 9
• SPI = GPIO 10, 11, 12, 13

We can also see a series of Tn pin definitions for the touch pins:

• T1-14 = GPIO 1-14

RGB and LED_BUILTIN

Also, whilst perusing the same file, I noticed the following comment:

// Some boards have too low voltage on this pin (board design bug)
// Use different pin with 3V and connect with 48
// and change this setup for the chosen pin (for example 38)
#define PIN_RGB_LED 48
// BUILTIN_LED can be used in new Arduino API digitalWrite() like in Blink.ino
static const uint8_t LED_BUILTIN = SOC_GPIO_PIN_COUNT + PIN_RGB_LED;
#define BUILTIN_LED LED_BUILTIN  // backward compatibility
#define LED_BUILTIN LED_BUILTIN  // allow testing #ifdef LED_BUILTIN
// RGB_BUILTIN and RGB_BRIGHTNESS can be used in new Arduino API rgbLedWrite()
#define RGB_BUILTIN    LED_BUILTIN
#define RGB_BRIGHTNESS 64

This is recognising that pin 48 was used by default for the RGB LED, but because of the possibility of pins 47 and 48 being configured for 1.8V operation for certain SPI flash memory configurations, means that it doesn’t work in some cases. Presumably this is why the official boards now use pin 38 for the RGB LED instead.

Note, I don’t know why LED_BUILTIN = SOC_GPIO_PIN_COUNT + PIN_RGB_LED, but I’ve seen elsewhere, in cores/esp32/esp32-hal-rgb-led.c:

#ifdef RGB_BUILTIN
  pin = pin == RGB_BUILTIN ? pin - SOC_GPIO_PIN_COUNT : pin;
#endif

The provided BlinkRGB.ino example works fine with the official board and my clone. Both boards are configured as follows:

• Connect via USB port (not the COM port).
• Board: ESP32S3 Dev Module
• All other settings: Defaults

And using Serial.print for PIN_RGB_LED confirms that the RGB is on GPIO 48 for both my boards.

I2C GPIO

In terms of I2C, it is possible to select which pins to use, if the defaults (8, 9) are not desired. to do this, just pass some pin numbers into the Wire.begin call as follows:

Wire.begin(I2C_SDA, I2C_SCL);

Note that this is different to how this is done on a RP2040 which has its own setSDA() and setSCL() functions. At least in the unofficial core. I don’t know if this is even possible with the “official” RP2040 Arduino core, but I’m getting off-topic…

Closing Thoughts

For some reason, from what I’d read I was expecting an obvious leap in performance moving from an ESP32 to a ESP32S3, but now I’m not so sure it will make much difference.

I’ll just have to give things a go and see what happens!

Kevin

#esp32 #ESP32s3 #ifdef #pcb

@tubetime I miss #ifdef... What a great way to knock out a 💩 ton of code.

Small success today - my Cinepak player can now auto-detect AVI and Quicktime (mov) files and play videos from either. Still some things to fix, but it's coming along. The lite/low-memory version is enabled with an #ifdef. I'm thinking of making this a runtime choice, but it creates some challenges.

Oh hey the kernel's copy of l.s has (behind `#ifdef BOOT`, which is never defined) that "same" code, but didn't forget to set GS and FS.

#Plan9 1e had a lot of bad code-duplication that should have been code-reuse. Actually, later editions are still pretty bad about this too.

#RetroComputing #ReverseEngineering

@foone

Agreed, but there's also a lot of `#ifdef __GNU_SOURCE` and such in the open-source world, too.

(Possibly relevant to @b0rk 's interests)

So I hit a flag in diff, --unchanged-group-format. It does not show up in the manpage. It does not show up in --help. You can search both those channels for that string and you will not find it.

You know where it shows up first? If you Google it, you'll get an example in https://www.gnu.org/software/diffutils/manual/html_node/Line-Group-Formats.html.

So why doesn't it show up in the manpage? Well, it does! If you read the entire manpage. With your eyes.

  -D, --ifdef=NAME                output merged file with '#ifdef NAME' diffs                                                                                                                                                                                                                                                                                                              
      --GTYPE-group-format=GFMT   format GTYPE input groups with GFMT                                                                                                                                                                                                                                                                                                                      
      --line-format=LFMT          format all input lines with LFMT                                                                                                                                                                                                                                                                                                                         
      --LTYPE-line-format=LFMT    format LTYPE input lines with LFMT                                                                                                                                                                                                                                                                                                                       
    These format options provide fine-grained control over the output                                                                                                                                                                                                                                                                                                                      
      of diff, generalizing -D/--ifdef.                                                                                                                                                                                                                                                                                                                                                    
    LTYPE is 'old', 'new', or 'unchanged'.  GTYPE is LTYPE or 'changed'.    

"What do you mean it isn't documented? Of course it's documented. You did read every line and do some template-substitution in your brain, didn't you?"

This isn't advocating for not reading the manpage. If you really want to understand how the tool works, you read the whole manpage. And probably the source code. 😉

... but I don't want to understand how the tool works. I want to diff two files and not have the lines that are the same get emitted.

And I think a lot of application- and solution-generating computer people, most of the time, in most of their careers, are operating on that level of depth. Problems come in too fast and with too much variety. You absolutely go deep on some things. There is no time to go deep on everything.

So how do we address this (other than throw up our hands and say "Relying on Google's fuzzy search of the whole Internet and vibe-coding LLMs is the future actually")? I don't have magic bullets, but a "fuzzy search" mode in something like less that could take an input like --unchanged-group-format and twig that it if there's no exact match, it might be related to --GTYPE-group-format would be nice.

Maybe I should mock that up in emacs. Actually, I bet someone already put it in emacs. ;)

#emacs #manpage #less

うーん。FreeDV-GUI、sioclientが無いことを想定していない作りになっているのでsioclient抜きのビルドをしたいとなるとかなり大掛かりな修正が必要になりそう。

（#ifdef~#endifで切るよりは、ダミーに置き換えたコードを作った方が良いのかも）

static const struct memdev {
    const char *name;
    const struct file_operations *fops;
    fmode_t fmode;
    umode_t mode;
} devlist[] = {
#ifdef CONFIG_DEVMEM
    [DEVMEM_MINOR] = { "mem", &mem_fops, 0, 0 },
#endif
    [3] = { "null", &null_fops, FMODE_NOWAIT, 0666 },
#ifdef CONFIG_DEVPORT
    [4] = { "port", &port_fops, 0, 0 },
#endif
    [5] = { "zero", &zero_fops, FMODE_NOWAIT, 0666 },
    [7] = { "full", &full_fops, 0, 0666 },
    [8] = { "random", &random_fops, FMODE_NOWAIT, 0666 },
    [9] = { "urandom", &urandom_fops, FMODE_NOWAIT, 0666 },
#ifdef CONFIG_PRINTK
    [11] = { "kmsg", &kmsg_fops, 0, 0644 },
#endif
};