MSI/Katana Tarzı RGB Klavyeleri Linux’ta Konuşturmak: PID Uyumsuzluğunu Kendiniz Çözün

tarafından Halil İbrahim K. Tarihinde Ağu 4, 2026

İçerik Tablosu

MSI/Katana Tarzı RGB Klavyeleri Linux’ta Konuşturmak: PID Uyumsuzluğunu Kendiniz Çözün

Yeni aldığım GameGaraj Slayer 4 (i7-14700HX + RTX 4060) laptopta CachyOS kurduktan sonra karşılaştığım ilk “gerçek” donanım sorunu klavye RGB aydınlatmasıydı. Windows’ta bu tarz laptoplarda genelde üreticinin kendi yazılımı (SteelSeries Engine, MSI Center vb.) devrede oluyor; Linux’a geçince o kontrol tamamen ortadan kalkıyor ve klavye ya son ayarında donup kalıyor ya da hiç yanmıyor.

Açık kaynak dünyasında bu işi çözen küçük ama işlevsel projeler var. Ben sarpowsky/msi-katana-rgb projesini denedim. Proje hidapi üzerinden USB HID protokolüyle klavyeyle konuşuyor, ama repodaki README.md net bir uyarıyla karşılıyor sizi:

“Eğer PID değeriniz 0x1601‘den farklıysa lütfen GitHub üzerinden bir hata kaydı (issue) açın.”

Benim laptopta çıkan Product ID (PID) 0x1601 değil, 0x1603 idi. Issue açıp beklemek yerine kodu kendim uyarladım ve klavyeyle haberleşmeyi sağladım. Bu yazıda hem ne yaptığımı hem de sizin kendi cihazınızdaki farklı bir PID için aynı yöntemi nasıl uygulayacağınızı anlatıyorum.

Not: Bu yöntem sadece USB HID üzerinden çalışan, “vendor-specific” basit protokollü RGB klavyeler için geçerlidir. Cihazınızın protokolü tamamen farklıysa (örneğin farklı bir üretici/çip seti), sadece PID değiştirmek yetmez — aşağıda “İşe yaramazsa ne yapmalı?” bölümüne bakın.

Önce: PID/VID Değerinizi Nasıl Bulursunuz?

Herhangi bir şeyi değiştirmeden önce cihazınızın gerçek kimlik bilgilerini öğrenmeniz gerekiyor. Terminalde:

lsusb

MSI klavyeler genelde 1770:xxxx (Vendor ID: MSI) formatında görünür. Çıktıda kendi klavyenizi bulun, örneğin:

Bus 001 Device 005: ID 1770:1603 MSI Katana RGB Keyboard

Buradaki 1770 Vendor ID (VID), 1603 ise Product ID (PID). Projenin desteklediği varsayılan değer 0x1601; benimki 0x1603 çıktı. Sizinki büyük ihtimalle bu ikisinden biri olacak ama farklı bir model/üretim yılıysa tamamen başka bir değer de görebilirsiniz — önemli olan lsusb çıktısındaki gerçek sayıyı kullanmak.

Eğer lsusb çıktısı belirsizse, daha ayrıntılı bilgi için:

lsusb -v -d 1770: | grep -E "idVendor|idProduct|iProduct"

1. Adım: Python Kodunda PID’i Güncellemek

Projeyi klonlayın ve ana dosyayı açın:

git clone https://github.com/sarpowsky/msi-katana-rgb.git
cd msi-katana-rgb
nano src/keyboard.py

Dosyada klavyeyi tanımlayan satırı bulun:

PRODUCT_ID = 0x1601

Bunu kendi lsusb çıktınıza göre değiştirin:

PRODUCT_ID = 0x1603

Ctrl+O, Enter, Ctrl+X ile kaydedip çıkın.

2. Adım: Udev Kuralını Güncellemek

Her komut için sudo yazmak zorunda kalmamak (ve programın normal kullanıcı olarak HID cihazına erişebilmesi) için udev kuralını da güncellemeniz gerekiyor:

nano 99-msi-katana-rgb.rules

Dosyada idProduct=="1601" şeklinde geçen satırları bulup kendi PID’inize göre değiştirin, örneğin:

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1770", ATTRS{idProduct}=="1603", MODE="0666"

Kaydedip çıktıktan sonra kuralı sisteme kopyalayın ve yeniden yükleyin:

sudo cp 99-msi-katana-rgb.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger

Bu noktada klavyeyi USB’den çıkarıp takmanız (veya laptopu yeniden başlatmanız) izinlerin oturması açısından iyi bir fikir.

3. Adım: Tek Komutla Otomatik Kurulum Betiği

Yukarıdaki iki adımı her yeni kurulumda elle tekrarlamak yerine, PID’i otomatik tespit edip değiştiren ve udev kuralını sisteme tanıtan bir betik yazdım. Bunu oto_kurulum.sh olarak kaydedin:

#!/bin/bash
set -e

echo "=== MSI/Katana Tarzı Klavyeler için RGB Otomatik Kurulum Aracı ==="

# 1. Bağımlılıklar (Arch/CachyOS ve Debian/Ubuntu tabanlı dağıtımlar için)
echo "Gerekli bağımlılıklar kontrol ediliyor..."
if command -v pacman &> /dev/null; then
    sudo pacman -S --needed git python python-pip hidapi --noconfirm
elif command -v apt &> /dev/null; then
    sudo apt update && sudo apt install -y git python3 python3-pip python3-hid
fi

# 2. Depoyu klonla
if [ ! -d "msi-katana-rgb" ]; then
    git clone https://github.com/sarpowsky/msi-katana-rgb.git
fi
cd msi-katana-rgb

# 3. Cihazın gerçek PID değerini lsusb'den otomatik yakala (MSI VID: 1770)
DETECTED_PID=$(lsusb -d 1770: | grep -oP '1770:\K[0-9a-fA-F]{4}' | head -n1)

if [ -z "$DETECTED_PID" ]; then
    echo "Hata: 1770 (MSI) VID'ine sahip bir USB HID cihazı bulunamadı."
    echo "Klavyenin USB üzerinden bağlı olduğundan emin olun ve 'lsusb' ile kontrol edin."
    exit 1
fi

echo "Tespit edilen PID: 0x$DETECTED_PID"
echo "Donanım kimlikleri (0x1601 -> 0x$DETECTED_PID) olarak güncelleniyor..."

find . -type f \( -name "*.py" -o -name "*.rules" -o -name "README.md" \) \
    -exec sed -i "s/0x1601/0x$DETECTED_PID/g" {} +
find . -type f \( -name "*.py" -o -name "*.rules" -o -name "README.md" \) \
    -exec sed -i "s/idProduct}==\"1601\"/idProduct}==\"$DETECTED_PID\"/g" {} +

# 4. Udev kuralını sisteme kopyala
if [ -f "99-msi-katana-rgb.rules" ]; then
    echo "USB HID izinleri sisteme tanımlanıyor..."
    sudo cp 99-msi-katana-rgb.rules /etc/udev/rules.d/
    sudo udevadm control --reload-rules
    sudo udevadm trigger
fi

# 5. (İsteğe bağlı) Klavyeyi sabit beyaza ayarla
echo "Klavye ışıkları varsayılan olarak beyaza ayarlanıyor..."
sudo python3 -c '
from src.keyboard import MSIKeyboardRGB, EFFECT_STEADY
try:
    with MSIKeyboardRGB() as kb:
        kb.select_zones(255)
        kb.set_effect(effect_type=EFFECT_STEADY, colors=[(255, 255, 255)])
        kb.save_to_flash()
        print("Başarılı: Klavye kalıcı olarak beyaza sabitlendi!")
except Exception as e:
    print(f"Uyarı: Işıklar ayarlanamadı ama kurulum tamamlandı. Hata: {e}")
'

echo "=== Kurulum Tamamlandı! ==="

Çalıştırma izni verin ve başlatın:

chmod +x oto_kurulum.sh
sudo ./oto_kurulum.sh

Bu sürüm, önceki elle-değiştirme yönteminden farklı olarak PID’i sizin yerinize lsusb‘den otomatik okuyor; yani betiği hangi MSI/uyumlu klavyede çalıştırırsanız çalıştırın, doğru değeri kendisi bulup kod içine işliyor. Böylece “1603 yerine sizin PID’iniz neyse” diye tek tek kod değiştirmenize gerek kalmıyor.

Farklı Dağıtımlarda Neler Değişir?

Arch tabanlı (CachyOS, Arch, EndeavourOS, Manjaro): pacman -S python python-pip hidapi yeterli. paru veya yay kullanıyorsanız hidapi genelde resmi depoda olduğu için AUR’a gerek kalmıyor.
Debian/Ubuntu tabanlı: python3-hid paket adı dağıtıma göre değişebilir; bulunamazsa pip install hidapi --break-system-packages ile Python tarafından kurabilirsiniz.
Fedora: sudo dnf install python3-hidapi genelde yeterli; udev kuralı adımı aynı kalıyor.
Masaüstü ortamı (GNOME/KDE Plasma vb.) fark etmez — çünkü burada devrede olan katman masaüstü değil, doğrudan udev + USB HID. Hangi DE’yi kullanırsanız kullanın, çekirdek aynı cihaz düğümünü (/dev/hidrawX) görüyor.

İşe Yaramazsa Ne Yapmalı?

Benim durumumda haberleşme sağlandı ama her fonksiyon (özellikle bazı efekt modları) birebir orijinal 0x1601 modeliyle aynı çalışmadı — muhtemelen aynı ürün ailesinin farklı bir revizyonunda küçük protokol farkları var. Eğer sizde de böyle bir durum olursa:

lsusb -v çıktısını saklayın. bInterfaceProtocol, bcdDevice gibi alanlar farklı revizyonları ayırt etmede işe yarar.
USB trafiğini dinleyin. Windows tarafında üreticinin kendi yazılımı çalışırken Wireshark + usbmon (Linux tarafında) veya USBPcap (Windows’ta, sanal makineden Linux’a aktararak) ile hangi HID raporlarının gönderildiğini karşılaştırabilirsiniz. Bu, farklı bir revizyon için protokolü tersine mühendislikle çözmenin en pratik yolu.
Projeye geri katkı verin. PID’inizi ve varsa protokol farklarını orijinal repoya bir issue/PR olarak bildirmek, sizden sonra aynı sorunu yaşayacak kişilere de yardımcı olur.

Özet

Açık kaynak bir donanım kontrol aracının desteklemediği bir PID’e sahip olmak, o aracı kullanamayacağınız anlamına gelmiyor. Çoğu zaman fark, kod içinde sabitlenmiş (hardcoded) tek bir sayı. lsusb ile gerçek kimliğinizi öğrenip bunu ilgili yerlerde güncellemek — ve tekrarlayan kurulumlar için bunu bir betiğe dönüştürmek — hem zaman kazandırıyor hem de “issue açıp cevap bekleme” sürecini ortadan kaldırıyor.

Bu yazıyı, benzer bir PID uyuşmazlığıyla karşılaşan başka birinin işine yarasın diye yazdım. Kendi cihazınızda denerseniz ve farklı bir sonuç alırsanız, yorumlarda ya da jn7.net üzerinden bana ulaşabilirsiniz.

Kaynak proje: sarpowsky/msi-katana-rgb — bu yazı, projenin kendisiyle değil, farklı bir PID’e sahip donanımda nasıl uyarlanacağıyla ilgilidir.