nyanpasu64 nyanpasu64

so i was getting weird symptoms. the upper port in my macbook air stopped working, my hp laptop 65w charger stopped outputting voltage. i power-cycled the macbook, unplugged the charger, and it took several unplug attempts before it would output voltage again. i blew out the ports with a gas duster and thought it was back to normal.

today it stopped working again. blowing out the ports didn't work. i'd get intermittent charging in some orientations with my Pixel 4a charger, and no charging at all with my 65w. sometimes my usb-c power meter (mine works for most but not all devices, but blocks adjacent ports!) would register 5v entering the macbook rather than 20.

coincidentally my new android phone arrived today, i had to connect it to root it. ...yeah the bad usb port doesn't connect to pixel phone either. i realized it was likely my port was physically damaged, and it was time to disassemble to look.

apple self-service, manual codes when purchasing parts (you really should link to the specific device ra

Probing a VGA signal

2023-06-05:

In order to debug vsync placement in regular and interlaced modes, I ended up building a custom VGA cable to direct the video and vsync signals to my computer's sound card, while it's also outputting to a display so I can see what I'm doing. I purchased a passive VGA splitter (which you shouldn't actually use with two monitors each with a 75 ohm termination), plugged the base and one end into my regular VGA port and cable, and stuck wires into the green, vsync, and ground holes in the other output. Since I didn't have protoboard, I hot-glued these wires to a piece of cardboard, using surface-mount resistors to divide the vsync signal to a safer voltage for microphone jacks. This proved to be a mistake, with the cardboard being so floppy that I repeatedly snapped the resistors' metallized terminals off their bodies.

My first VGA probing rig had some truly terrifying signal properties, far worse than plugging my Wii's component 480p luma signal through a RCA splitter into

I've had to spend months figuring QAbstractItemModel out (though I haven't worked with parent-child trees yet). Now you will have the pleasure as well.

Qt's model-view system is a nightmarish abstraction thrusts the horror of the endless complexity on the end user; each model you implement is a subclass and a hundred lines, sometimes more, and KDE apps are composed of models stacked upon models, the inner workings of which are whispered about in hushed tones. Drag-drop is no exception, having three separate ways (to my knowledge) to implement it:

QAbstractItemView::startDrag() calls some platform-specific drag-drop code (OLE on Windows). If you perform an internal drop, this platform-specific code calls QListView::dropEvent(), which calls QAIM::moveRow().
If it fails, or on non-QListView subclasses, QAbstractItemView::dropEvent() calls QAbstractItemModel::dropMimeData() which either replaces data or calls QAbstractItemModel::decodeData() which calls insertRows(). Once the platform-specif

let mut v = vec![0; 10];
let a = &mut v;

// braces not necessary with NLL.
{
    // let b = a; // moves a, doesn't compile.
    let b = &mut *a; // stacked borrow of a, compiles.
}
*a = vec![];

ExoTracker timeline system

Timeline

The frame/order editor is replaced with a timeline editor, and its functionality is changed significantly.

The pattern grid structure from existing trackers is carried over (under the name of grid cells). Each grid cell has its own length which can vary between cells (like OpenMPT, unlike FamiTracker). However, grid cells are not patterns, and events are not placed directly in grid cells.

Events are placed in a separate nested structure. Each channel has its own timeline, or an array of one timeline cell per global grid cell. The length of a timeline cell is determined by the corresponding grid cell. A timeline cell can hold zero or more blocks, which carry a start and end time (in integer beats) and a pattern. These blocks have nonzero length, do not overlap in time, occur in increasing time order, and lie between 0 and the timeline cell's length (the last block's end time can take on a special value corresponding to "end of cell")[1].

	#!/bin/bash
	systemctl --user stop plasma-plasmashell

	function stray_crt() {
	# nesdev server
	xrandr --newmode "1440x480i-60" 27 1440 1478 1602 1716 480 489 495 525 interlace
	# crt emudriver
	xrandr --newmode "1440x480i-60e" 27.31 1440 1480 1608 1736 480 487 493 525 interlace -hsync -vsync
	xrandr --newmode "1440x240p-60e" 27.26 1440 1480 1608 1736 240 244 247 262 -hsync -vsync
	xrandr --addmode HDMI-2 "1440x480i-60e"

	=============================================================================
	Anomie's S-DSP Doc - with updates/fixes/clarifications/etc by jwdonal
	$Revision: 1212 $
	$Date: 2015-09-28 00:41:22 -0700 (Mon, 28 Sep 2015) $
	<[email protected]>
	=============================================================================

	The S-DSP is the actual sound generator for the SNES. It shares 64K of RAM with
	the SPC700, and can be poked at via SPC700 registers $00F2 and $00F3. It has an
	input clock running nominally at 24576000 Hz, and supplies the SPC700 1024000

	# Maintainer: dokutan <???>
	# Contributor: nyanpasu64 <nyanpasu64 at tuta dot io>
	pkgname=rgb_keyboard-git
	_pkgbare="${pkgname%-git}"
	pkgver=0.2.r1.g28611e0
	pkgrel=1
	pkgdesc="Controls the RGB lighting on some keyboards (GMMK and others)."
	arch=(x86_64)
	url="https://github.com/dokutan/rgb_keyboard"
	license=('GPL3')