'분류 전체보기'에 해당되는 글 430건

BBQ20KBD라는 것은 그냥 쉽게 말하자면 BlackBerry Q20 Keyboard라는 의미입니다.

한때 엄청 유명했던 전설의 휴대폰 블랙베리 Q20의 키보드를 사용해서 일반적인 키보드를 만드는 프로젝트입니다.

https://www.solder.party/docs/bbq20kbd/

Solder Party라는 곳에서 제작 및 진행을 하고 있고 BlackBerry 키보드 부품도 필요하지만 잘 뒤져보시면 PCB와 함께 완제품?을 구할 수도 있습니다.

저는 운 좋게 완제품을 구해서 가지고 놀고 있었습니다.

그런데 이 키보드가 한/영키가 따로 존재하지 않습니다. 그래서 표준이라 할 수 있는 Shift+Space를 함께 눌러봤는데...

이상하게 작동이 안 되더군요.

이건 아무래도 펌웨어 문제가 분명했습니다.

공개된 펌웨어 코드를 다운로드 받아서 분석을 해보니...

https://github.com/solderparty/i2c_puppet

KEY_MOD_SHL

KEY_MOD_SHR

KEY_MOD_ALT

KEY_MOD_SYM

여기 있는 키는 입력을 씹는 것으로 되어 있습니다. 근데 씹는게 맞기는 합니다. 저 키는 원래 조합으로 만들어지는 부분이니까요.

원래 코드 기준 76번째 줄 보면 (위 스크린샷 기준 81번째 제가 좀 손을 봤거든요.)

tud_hid_n_keyboard_report(USB_ITF_KEYBOARD, 0, modifier, keycode);

이 함수로 키코드와 조합키를 만들어서 보내는 듯 합니다.

그러면 해당 함수를 호출 하는 곳을 찾아봅니다.

열심히 찾다보니 콜백 함수를 찾을 수 있었습니다. key_callback이라는 구조로 콜백하게 되어 있군요. 그러면 key_callback을 찾아봅니다.

여기저기 있었지만 찾아본 결과 keyboard.c에서

여기 있는 이 부분이 바로 중요한 부분이었습니다.

즉 keyboard_inject_event함수가 호출 될 때 해당 부분을 콜백하면서 작동되는 구조더군요.

그리고 해당 함수를 호출 하는 부분은 위쪽에 있었습니다.

transition_to 함수에서 키코드를 받아이런 저런 조합을 하는 부분이 있었습니다.

그래서 생각을 한 것이 해당 키보드의 SYM키 위치가 좋아보이더군요. 그래서 이걸 0xF2로 바꿔봤습니다. 0xF2가 한국키보드의 한/영 키를 의미합니다. 요즘은 그냥 오른쪽Alt키를 더 많이 쓰는 거 같지만 위 스크린샷의 109번째 줄 처럼 key=0xF2로 바꿔봤습니다.

그리고 해당 코드를 빌드 후에 키보드에 입혀봤습니다.

설명서를 보시면

여기 있는 해당 부분을 누르면서 USB를 연결하면 부트로더 모드로 진입하고 이때 뜨는 드라이브에 빌드된 uf2 파일을 복사하면 알아서 펌웨어가 입혀집니다.

(uf2파일로 빌드하는 것은 이전 글 https://moordev.tistory.com/451참조)

그랬더니 윈도우에서 잘 먹힙니다. 그런데 이건 윈도우에서 먹히는 거고 안드로이드에서는 또 안 먹힙니다.

안드로이드는 Shfit+Space가 아니면 언어 전환이 안 되거든요.

그래서 추가로 손을 댔습니다.

usb.c 파일의 key_cb 함수를 수정해서 저 위치에

이 코드를 추가하면 0xF2 코드가 들어왔을 때 Shift+space로 작동 되게끔 신호를 쏴줍니다.

이렇게 해주니 SYM키를 누를 때마다 한/영전환이 안드로이드에서 아주 잘 되기 시작합니다. 대신 윈도우에서 또 안 되네요...

윈도우가 Shift+Space 전환을 지원을 안 하는게 아닌걸로 아는데 이건 이유를 모르겠네요.

그냥... 이 키보드를 어디서 쓸거냐에 따라 그때그때마다 펌웨어를 바꿔주는 것으로 합시다... 굉장히 귀찮아지기 시작했습니다.

원한다면 다른 방식으로 그냥 키를 싹싹 바꿔보는 것도 방법일거 같기도 하네요.

RP2040은 라즈베리파이 재단에서 만든 ARM기반 MCU입니다. 

라즈베리파이 피코에 쓰인 것으로 유명하고 다른 MCU와 다르게 부트모드로 USB를 연결한 다음 뜨는 드라이브에 uf2파일을 복사하면 알아서 펌웨어가 들어가는 편리한 방식을 쓰고 있습니다.

문제는 uf2파일을 어떻게 만들것인가인데 우선 리눅스에서는

이런식으로 하라고 되어 있습니다. 그런데 이거 좀 많이 불편합니다. bashrc를 쓰는 것도 그렇고 문제가 많지요.

그래서 Docker를 통해서 빌드시스템을 만드는 것으로 바꾸기로 했습니다.

위 파일을 이용해서 도커 컨테이너를 빌드한 다음 그 안에서 빌드하는 것을 추천합니다.

다시 자세히 말하자면 우선 docker를 설치합니다.

sudo apt update

sudo apt install docker.io docker-compose -y

그리고 조금 위험할 수도 있지만 

sudo usermod -aG docker $USER

이건 사용자에게 도커 사용 권한을 부여하는 명령입니다. 만약 필요하면 쓰세요. 

(전 그냥 귀찮아서 씁니다.)

그다음 해당 파일을 다운로드 받거나 다음 내용으로 Dockerfile 파일을 만듭니다.

그 다음 Dockerfile이 있는 곳에서 다음과 같이 명령을 내립니다.

docker build . -t rpi-builder

그러면 이제 rpi-builder 태그가 붙은 컨테이너가 하나 빌드됩니다.

그리고 

docker run -it -v (로컬디렉토리내의 프로젝트 폴더경로):/project rpi-builder bash

이렇게 하면 도커 내부로 들어갑니다. (-v 옵션이 들어가 있는 것을 보실 수 있습니다. 해당 옵션은 로컬디렉토리와 도커내부 디렉토리를 볼륭링크하는 옵션입니다.)

cd /project

여기서 cmake와 make를 통해서 빌드를 하시면 됩니다. 

보통은 

mkdir build

cd build

cmake -DCMAKE_BUILD_TYPE=Debug ..

make

보통 이런식으로 명령을 내리지요. 빌드가 다 되었다면 uf2 파일이 만들어져 있을 겁니다. 이것을 부트모드로 들어간 라즈베리파이피코를 연결하고 해당 드라이브에 복사한 뒤 USB를 뽑았다 다시 연결하면 펌웨어가 적용 되어 있을 겁니다.

gcc의 최적화 옵션은 크게 4가지입니다

1.그냥 최적화 안 함
2. -O2 적당한 속도 최적화 적당한 크기 최적화
3. -O3 속도위주 최적화
4. -Os 크기 최적화

1.은 그냥 말그대로 최적화따위 없이 코드를 컴파일한 그대로 써먹겠다는 겁니다. inline으로 도배가 되어있거나 수동으로 최적화가 되어있는 방식이면 이걸 쓰는게 훨씬 효율적입니다.

2. 일반적인 옵션입니다. 보통은 이걸 쓴다고 보면 됩니다. 분기나 함수호출이 줄줄이 있다면 함수하나에 몰아넣거나 분기를 최대한 줄이는 등의 최적화를 합니다.
최적화로 인한 오류는 거의 없습니다.

3. 속도를 위해 최적화 하는 방식입니다. 파일크기를 희생해서 속도를 올립니다. O2에서 쓰는 최적화는 물론이고 자체적으로 지저분한 코드를 더 빠른 코드로 갈아치우기도 합니다. 대신 파일크기가 커지기 때문에 도리어 캐시메모리가 모자라 O2보다 느려지기도 하며 코드를 바꾸다가 오류를 일으키기도 합니다.

4. 그냥 작은 용량을 위해 쓰는 옵션입니다.
코딱지만한 임베디드쪽에서 주로 사용합니다. O2에서 MB단위였던게 KB단위로 만들어지는 기염을 토하기도 합니다.
다만 O3같은 생각지 못 한 오류가 드물게 있습니다.

보통 일반적인 코드는 O2를 이용해서 처리합니다. O3도 사실 오류가 있을 수 있다고 했지만 진짜 오류가 생기는 경우는 매우 드뭅니다. 그래서 요즘은 O3로 하는 경우도 많습니다.

요즘은 기본적으로 디스크가 남아돌아서 Os를 PC에서 쓰는경우는 거의 없고 대부분 임베디드장치에서 씁니다. 그리고 실행속도가 느려지기 때문에 (함수 내부 코드가 겹친다 싶으면 그걸 또 쪼개서 호출하기 때문에 매우 복잡해집니다) 속도가 중요한 임베디드 기기에서도 잘 안 씁니다.

그 외에 -O1도 있지만 이건 쓰는걸 보기 힘들군요.

아무튼 궁금해진차에
그래서 리눅스 커널을 O2 O3로 최적화해서 각각 돌려본 결과

정말 무의미한 속도차이만이 있었습니다. (실제 벤치마크를 돌리면 O3가 미묘하게 빠르다곤 합니다. 그런데 오차범위 이내 수준)
리눅스 커널 컴파일의 기본옵션이 O2인것은 다 이유가 있던겁니다.

혹시나 Os로도 해봤는데 커널이미지의 크기는 작아졌지만 역시 큰 차이는 없었습니다.

리눅스커널쯤 되면 크게 옵션에 의한 차이가 없는거 같습니다. 제가 임의로 짠 엉망진창 코드라면 달라질거 같은데 그것까지 하기엔 너무 귀찮군요.

Cachy OS는 Arch기반으로 게이밍에 최적화된 운영체제입니다.

사실 커널말고도 각종 프로그램을 최신 CPU에 맞춰서 싹 컴파일 해놓았지요. 다른것보다 게이밍에 초점을 맞춰서 상당한 성능향상을 본것으로 유명합니다.

사실 비슷한 것으로 이미 SteamOS가 있습니다. 특정 기기에 맞춰서 최적화를 해놓은 운영체제지요.

그런데 문제는 아시다시피 Arch리눅스를 쓰는 경우에는 그냥 CachyOS의 것을 그대로 적용 가능하지만 데비안/우분투는 적용이 안 됩니다. Pacman과 DEB(APT)의 차이지요. 대신 CachyOS가 사용한 패치를 적용해서 직접 커널을 컴파일한다면 얼마든지 사용이 가능할겁니다.

그러기 위한 저장소가 존재합니다.

https://github.com/CachyOS/linux-cachyos-deb

해당 스크립트는 사용자의 CPU를 확인해서 거기에 맞는 커널을 직접 컴파일 해주는 스크립트 입니다. 다만 해당 커널은 인증받은 커널이 아니므로 기본적으로 SecureBoot를 꺼주셔야 부팅이 가능합니다. 몇몇 대기업의 PC는 SecureBoot를 끌 수 없으므로 어쩔수 없이 인증받은 커널을 쓰셔야 합니다.

방법은 

git과 curl을 우선 설치하고 해당 git을 클론해옵니다.

sudo apt git curl

git clone https://github.com/CachyOS/linux-cachyos-deb.git

cd linux-cachyos-deb

그리고 안에 있는 스크립트를 실행 가능하게 해줍니다.

sudo chmod +x cachyos-deb.sh

./cachyos-deb.sh

그러면 필요한 패키지를 모두 설치하고 이것저것 물어보는데 CPU 아키텍처가 맞는지 SecureBoot를 껐는지 등등을 물어봅니다.

그리고 모든 것을 마치면 메뉴가 뜹니다.

여기서 다른 것보다 LLVM LTO부분이 신경 쓰이는데 본래 CachyOS는 LLVM LTO의 옵션이 THIN으로 되어 있습니다. 그런데 문제는 Nvidia드라이버와 충돌 일어납니다. 최신 버전에서는 충돌이 해결되었다고 하는데 저는 최신드라이버를 못 쓰는 그래픽카드기에 어쩔 수 없이 None으로 했습니다.(애초에 그래서 저는 CachyOS를 쓸 수 없습니다.)

그외는 그냥 기본값 그대로 하면 거의 맞습니다. 그리고 11 COMPILE KERNEL로 바로 커널 컴파일을 시도하면 gcc나 clang으로 커널 컴파일을 시도합니다. 한참 걸릴테니 그냥 켜놓고 주무시면 됩니다.

컴파일이 완료 되면 deb 파일이 덩그라니 나오니 이걸 설치하면 됩니다. 참고로 데비안의 경우는 현재 데비안 소스보다 더 최신의 커널을 올리게 되어 있으므로 이걸 설치하면 이후로는 해당 커스텀 커널을 이용해서 부팅하게 됩니다. VirtualBox같은거 쓸 때 커널버전 문제가 있을 수 있으므로 주의해주세요.

컴파일이 다 되었다면 linux-x.x.xx 폴더에 custom-kernel-header~~.deb과 custom-kernel-~~.deb두가지가 생성되었을 겁니다. 이걸 그냥 설치하면 됩니다.

sudo dpkg -i custom-kernel*.deb

sudo update-grub 

sudo update-initramfs -u -k 커널버전

커널버전은 update-grub을 했을 때 뜨는 버전명을 적어주시면 됩니다.

저 같은 경우에는 7.0.10이네요.

dkms에 의한 모듈이 작동되지 않을 텐데 이것도 추가로 해줍시다. deb 만들때 해주면 좋을 텐데 이것까지 수동이네요.

sudo dkms autoinstall -k 커널버전

만약 반응이 없다면 dkms를 이용해서 다시 모듈을 빌드해야 합니다.

sudo dpkg-reconfigure $(dpkg -l | awk '/-dkms/ {print $2}')

이렇게 하면 모든 모듈을 다시 빌드합니다. gcc버전을 바꾸거나 더 최적화를 시키려고 하신다면 유용하게 쓰실 수 있습니다.

이제 재부팅 해봅시다.

uname -r을 쳤을 때 해당 버전이 뜨면 성공입니다.

=============================2026 5. 31======================

쓰다보니 커널을 수정해야 하는 경우가 생겼습니다.

그래서 빌드 스크립트의 일부를 수정해서 쓰고 있습니다.

cachyos-deb.sh파일을 열어서 일부분을 수정해서 써야 어느정도 되겠더군요. 아무래도 아직 테스트 버전이라 이래저래 문제가 많은 거 같습니다.

1. 442번째 줄에 SCHED_EXT+BORE 스케줄러(일명 cachyos 스케줄러)를 적용하려고 하니 SCHED_EXT패치가 어느순간부터 사라져서 패치적용이 안 되는 문제가 있었습니다.

그래서 기본 스케줄러를 bore+cachy 패치로 교체하기 위해서

아래 bore와 동일한 패치로 내용을 교체하였습니다. 스크립트에선 bore 스케줄러 단독만 적용되는 메뉴가 아에 없더군요.

두번째로 initramfs의 크기가 너무 커져서 부팅속도가 엄청 느려지더군요. 그래서 알아봤더니 모듈에 디버그 심볼이 들어가서 그렇답니다.

그래서 381번째 줄 make modules_install 사이에 https://unix.stackexchange.com/questions/30345/why-is-my-initial-ramdisk-so-big

여기 나온 것처럼 INSTALL_MOD_STRIP=1  을 적어서 모듈에 디버그 심볼을 제거 해야 했습니다.

세번째는 특정 버전 커널이 필요할 때 입니다.

전 낡은 하드웨어라 개인적으로 7.0에서 문제가 많이 발생해서 6.12버전으로 다시 낮춰야 했습니다.

그런데 이 스크립트는 무조건 최신 커널을 사용하더군요.

그래서 

565번째 줄 _kv_url 부분을 제가 필요한 리눅스 커널 소스 타르볼로 강제 지정했습니다.

기존 코드를 앞에 #을 붙여 주석처리 한다음

_kv_url = "내가 원하는 리눅스커널 소스"

해당 소스코드는 kernel.org에서 링크를 직접 복사해서 붙여 넣어주시면 됩니다.

더 정확한 특정 버전을 원한다면

https://www.kernel.org/pub/linux/kernel/

여기에서 직접 특정 버전의 tar.gz 파일의 링크를 복사해서 넣어주시면 됩니다.

예를 들어 6.6.1버전이면 v6.x 폴더로 들어간다음 리스트를 쭉 내려서 

linux-6.6.1.tar.gz 파일의 링크를 복사해서 해당 위치에 복사하면 됩니다.

그러면 이후 스크립트에선 강제로 해당 버전을 지정해서 사용하게됩니다.

그 다음에 똑같이 스크립트에서 이리저리 손을 댄다음 빌드하면 됩니다.

wayland가 등장한지 어언 15년? 정도 됐습니다.
기존의 X11의 문제도 해결하고 낡은 코드도 줄일겸 등장했지요. 그런데 이거 아직도 문제가 있습니다.

요즘은 KDE와 Gnome같은 메이저 환경이 Wayland를 기본으로 지원하고 있기에(심지어 KDE는 X11지원을 없앴지요) 사실상 Wayland가 강제되고 있는데 Wayland의 개발이 안정화된 지금도 불만이 여기저기서 튀어나오고 있습니다.

1. X11에서 잘되던데 안 됨
대표적인게 원격지원이지요. VNC가 아무래도 X11을 상정하고 만들어진거다보니 Wayland랑은 뭔가 잘 안 맞습니다. 마치 윈도우에서 VNC를 돌리는 느낌이랄까요?
그리고 SSH에서 ForwardingX 해보신분들이라면 원격PC에서 서버에서 돌리는 프로그램을 Seamless하게 돌리던 기억이 있을겁니다. Wayland는 이거 잘 안 됩니다.

2. 가상머신에서의 문제
네이티브는 크게 문제가 없습니다. 그런데 리눅스는 특성상 가상환경에서도 많이 돌아갑니다. VirtualBox나 VMWare, 하다못해 Hyper-V에서도 돌아갑니다.
그런데 가상머신위에서 KDE를 쓰면 화면이 자주 깨집니다. X11시절에선 KDE가 아주 멀쩡했거든요. 이건 아무래도 가상머신의 드라이버 문제라고 보입니다만 가상머신의 지원이 늦는다는거 부터가 문제라고 생각됩니다.

3. 드라마틱한 성능향상이 없음
일단 Wayland구현체들 대부분이 메모리를 적게 먹긴합니다. 근데 호환문제로 인해 Xwayland를 안 쓸수는 없기에 Xwayland를 올리면 메모리 사용량은 비슷해집니다.
그러면 반응은 빠른가? 네 숫자상으로는 빠르긴합니다. 그런데 또 크게 체감이 안 든다는게 또 문제입니다. 120Hz부터는 체감이 된다고 하는데 제 작업용 PC는 아직 60Hz입니다.

4. 한글입력문제
Kime의 등장이후 해결되긴했습니다만 역사와 전통의 한글입력기들은 고통받고 있습니다. Kime도 똑같이 고통속에서 여러 우회기능으로 우회하는듯 합니다.
중국어나 일본어가 쓰는 로마자입력방식이 아닌 한글을 다이렉트로 치는 한국어는 너무 고통스럽습니다.

그리고 제 PC는 Wayland가 불안해서(퍼킹 Nvidia) 메인을 Xorg로하고 Wayland가 필요할때마다 weston을 따로 실행한 후 여기서 프로그램을 실행하고 있습니다. 어떻게 된게 wayland위에서 Xwayland를 쓰는것보다 이쪽이 더 안정적입니다.

그러다보니 아직 Xorg가 주력인 xfce4에 데비안 시스템을 주력으로 하고있습니다. 마음같아선 저도 KDE를 쓰고 싶은데 KDE만 쓰면 Wayland때문에 자꾸 문제가 펑펑 터지네요.

리눅스란게 뭔가 급진적인 OS이미지가 있던데 저는 반대로 엄청 보수적인 사용자가 된거 같습니다.
아무래도 5년은 지나야 Wayland로 넘어갈지도...

샤오미 스마트폰은 그래도 2026년 현재 그나마 커스텀롬(LineageOS, Pixel Experience등)이 그나마 활성화된 스마트폰입니다.

아무래도 기본OS인 하이퍼OS가 보안관련 찝찝함이 있는데다 묵직한편이라 AOSP기반으로 뜯어고치는 경우가 많기 때문이지요.

다른 스마트폰 제조사의 경우 기본OS로도 괜찮거나 기본OS가 아니면 안되는 기능이 많은데 샤오미는 그냥 갈아엎는게 낫다고 할 정도로 하이퍼OS의 완성도가 썩 좋지 못 합니다.

저는 샤오미의 레드미노트 12 5G를 갖고있는데 커스텀롬으로 당연히 엎었습니다.

그러고나니 무슨이유인지 와이파이가 영 안 잡히더군요. 저는 당연히 공유기 문제겠거니 했는데 공유기를 바꿔도 성능이 영...

근데 웃긴건 옆에있는 갤럭시는 와이파이가 빵빵하다는겁니다. 이유를 알길이 없었는데 최근에 퀄컴칩셋에 한해 와이파이 본딩이 꺼져있다는것을 알게 되었습니다.

와이파이 본딩이란 주파수 대역 2개를 함께써서 속도와 안정성을 높이는 기술입니다. 5Ghz대역은 널찍하기 때문에 본딩해서 쓰는게 이득이고 또 대다수 기기들이 지원합니다.

그런데 이 놈의 샤오미폰은 본딩이 꺼져있었습니다. 그래서 주파수대역이 협소한 나머지 접속이 불안정했던겁니다.
이걸 2년만에 알았네요.

해결방법은 일단 Magisk를 적용해야합니다. 부트이미지를 덤프하고 커널이미지에 심고 이를 다시 플래시 하는 일련의 작업이 필요합니다만 이쪽에선 넘기겠습니다.

그리고
https://github.com/Magisk-Modules-Repo/wifi-bonding

요 모듈을 적용합니다. 그리고 재부팅을 하면 갑자기 100Mbps나올까말까한 와이파이가 280이 넘게 잡히면서 빠르고 안정적이게 됩니다.

기본OS인 하이퍼OS도 와이파이 불안하다는 소리가 들리는데 샤오미는 루팅이 기본이어야 할 듯 합니다...

ipTime공유기는 한국점유율 1위에 빛나는 공유기입니다. 적당한 가격과 적당한 성능 그리고 적당한 디자인으로 지금도 팔리고 있지요.

몇몇 사람들은 Iptime의 성능과 내구성문제로 까기도 하지만 이 정도로 소프트웨어 관리해주는 업체도 사실 드뭅니다. ASUS와 TP-Link가 뒤를 따르고 있지만 이쪽은 이쪽대로 어지간한문제가 펑펑 터지지요.

그러다보니 저도 ipTime을 쭉 쓰고 있습니다. 항간에선 중국 ZIONCOM 택갈이 아니냐고 하는데 지온콤은 사실 생산공장이고 연구개발은 한국에서 하고 있습니다. 한국에서 생산하면 그 가격이 불가능하기에 지온콤에 맡긴 방식입니다.

그런데 이러한 제품에도 고질병이 있으니 일명 어댑터문제.

사실 공유기는 PC나 가전제품과 다르게 24시간 켜져있다보니 어댑터가 상시 켜져있습니다. 그래서 내구성문제가 매번 터지는데 2년?이 보통 한계인거 같습니다.

그래도 최근은 그나마 낫습니다. 이전에는 이름도 처음들은 이상한 회사의 어댑터를 끼워줬는데 그래도 최근에는 지온콤(그러니까 제조사 이름이죠)의 이름을 단 어댑터를 끼워주더군요.

그래도 자사(정확히는 제조사지만)의 이름으로 제조했으니 성능이나 내구성은 이전보다 나아졌을겁니다.

하지만 이것도 오래쓰다보니 언제부터인지 연결이 불안불안한게 좀 신경 쓰이더군요.

아무리 제조사가 직접 제조한다고 해도 결국 어댑터의 부품은 결국 망가지는건 똑같겠지요.

그래서 어댑터를 새로 샀습니다.
전압은 동일한 대신 허용전류는 조금 더 큰걸로요.
위에 사진보면 12V 2A인데 12V 3A로 바꿨습니다.
이러면 발열량이 더 줄어서 내구성문제에서 조금더 좋아집니다.

또 가능한 PFC가 있는 제품을 쓰는게 좋은데 전력효율이 엄청 좋기 때문에 발열량이 줄어듭니다. 노트북용 어댑터들이 그러합니다. 하지만 PFC가 없더라도 전류 용량이 큰게 가격대비 성능이 낫긴합니다.

4A이상되면 그냥 노트북 어댑터나 모니터용 뿐이더군요.

오디오쪽으로가면 접지된거가 좋니 어쩌니 하던데 공유기는 어차피 디지털기기이기 때문에 접지 노이즈의 영향이 미미 합니다. 그냥 전류 넉넉한걸로 쓰고 과열방지나 과전류가 들어간거 쓰면 어지간해선 오래 쓸 수 있을겁니다.

어댑터 중에는 직류쪽에 노이즈 필터가 달린게 있어서 서지를 어느정도 막을 수 있기도 합니다.

우선 국내에서 내노라하는 두 업체(명호전자, 안전사)의 것을 써봤는데 과연 어떨지... 지켜봐야겠지요.