Salvador Liébana

  • Content Count

    47
  • Joined

  • Last visited

Everything posted by Salvador Liébana

  1. many thanks for your time. it did not resolve the problem but it switched to modsetting Graphics: Device-1: display-subsystem driver: rockchip_drm v: N/A bus ID: N/A Device-2: rk3399-dw-hdmi driver: dwhdmi_rockchip v: N/A bus ID: N/A Device-3: rk3399-mali driver: panfrost v: kernel bus ID: N/A Display: x11 server: X.Org 1.20.9 driver: modesetting resolution: 1920x1080~60Hz OpenGL: renderer: Mali T860 (Panfrost) v: 3.1 Mesa 21.1.0-devel (git-befd9fb 2021-03-21 focal-oibaf-ppa) what component of those it's the faulty or the one wi
  2. @lanefu here it seems I am currently on modesetting (this is part of the inxi -Fx output) : Display: x11 server: X.Org 1.20.9 driver: modesetting unloaded: fbdev soy maybe its a limitation from the diusplay subsystem? Device-1: display-subsystem driver: rockchip_drm v: N/A bus ID: N/A . what I am asking its where you identify that the SoC limitation (...a driver or kernel driver limitation) is.
  3. obviously not, he is not a moron rpi fan boy. he use real hw, rk3399. the performance dramatically changed with the overlay.. so yes, its needed somehow, thanks for the answer @piter75 I will give you proper feedback soon.
  4. okay, I have this on /etc/X11/xorg.conf.d/01-armbian-defaults.conf Section "Monitor" Identifier "Monitor0" Option "DPMS" "false" EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection do you use n2 for desktop. shame on you. haha just joking... but rk3399 is better desktop on my humble opinion.
  5. HI guys, one guy at my server realized some nvme testing and the write speed results are far below compared to radxa official benchmark that's probably based on legacy kernel. anyone had better benchmarks on write speeds without legacy kernel (so, mainline)
  6. thanks for your fast reply @lanefu!! I have this extra info. I am surprised bc it seems that the initial config want to expose 640x480 (without doing it manually) but something disallow it. if its a soc limitation that could be resolved by software (kernel dev) or not I need to know it. oh, it says fb. maybe I should try the other one.. how i switch to that one? also, do you know how to shift to gbm from x11? i mean on rpi4 we can just do ctrl plus F4. maybe there is a way to trigger something similar. usually gbm its a better performing enviro
  7. Hi guys! I need to run some game on full screen, and they are old school windows one. the thing is that adding the modeline worked perfectly fine on rpi4, not on armbian sadly. it seems to change the resolution and then it go "out of signal". I used the same parametes than on rpi4. also generated new ones just in case. the thing is I cant make it to work and maybe iut's something deep into armbian. exaple: xrandr --newmode "640x480_60.00" 23.75 640 664 720 800 480 483 487 500 -hsync +vsync xrandr --addmode HDMI-1 640x480_60.00
  8. @Igor run glmark2 on default compositor mode (auto is GLX) we get glmark results 5-6 times lower than on xpresent mode. to test it: xfwm4 --vblank=xpresent --replace to replace it by default (this will work after reboot) xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "xpresent" --create rerun glmark2... you will see the differences. at this point it's quite ridiculous that xfce4 compositor defaults to GLX... mesa devs hate it... his drivers too.
  9. for XFCE we must have it on xpresent mode by default. the differences with GLX mode are quite high on GL @Igor
  10. HI folks, I wonder how to do that.. it's that simple. on RPI OS is just ctrl + alt + F4, maybe here is more complex.
  11. then, hopefully @piter75 and @balbes150 will check about it.
  12. Hi!! what about this guys , it could be available on armbian later on?? https://github.com/LibreELEC/LibreELEC.tv/pull/4988
  13. Hi guy's! anyone had experienced wifi desconections and very low wifi performance overall on mainline?? I have those on any of my rk3399s sadly. does anybody tried a workaround?? it's a really bad chip but on rpi4 it performs quite better (sadly). I also not experienced this kind of performance on previous kernels.
  14. quote: Starting with Ubuntu 19.04 binder and ashmem are now build with the standard Ubuntu kernel (>= 5.0) and you don’t have to install the modules from the PPA anymore.
  15. well, ubuntu kernels seems to have them by default nowdays. the problem with the modules is that sometimes they install.. and sometimes doesn't. I tried to install this kernel modules several times on armbian 5.8+ and it have many problems lately (not only on ARM obviusly). they don't care that much bc ubuntu already have those by default. adding them by default it's just... enabling them on the script... I don't know how much impact could have enabling them for people that would not use them. I am thinking on the long run on reliability as desktop.. and h
  16. Hi Folks! I think this would be great for testing Anbox easily on armbian. We are linux users (and we hate android), but in order to get ARM Linux attractive as desktop we may have to offer anbox. the kernel modules have problems on latest kernels so would be great to have them included already. maybe that makes the kernel "too big" and isn't acceptable, but that's up to you to consider it or not. best regards, Salvador.
  17. we have a very solid reputation. we are the team behind one of the most popular RPI4 builds and we are tired of RPI4 fanatism while the hardware clearly sucks. so, if that isn't enough for you or fpr anyone else, they can avoid this custom armbian build. we do care on newcomers to ARM Linux. we don't like to be a marginal platform for pro user's. We want ARM Linux to be friendly for any newcomers as RPI community offer to the rubbish Broadcom SBC'S. we don't need that pro user's use it or like it at all. but we present it for the newcomer's that know what we do and know our reputation.
  18. and we don't care if you don't like it. it's for noobs. not for pro user's like you. the feedback take place on our discord for TwisterOS Armbian. the problems it have (xfce4 working like shit) are present on vanilla Armbian. if you wanna help, just do it from vanilla.
  19. setting the governor to performance should not change this situation. I did not have those hangs on mate, but right now armbian on RK3399 under xfce, the official desktop environment of Armbian, is extremely unstable. it hangs randomly. most of the time on browsing. this should be a priority, the OS doesn't work on mainline. it hangs randomly. and yes, maybe it's platform specific, but RK3399 is the moat widely used SoC, so this requiere a fix. I don't have a UART so it's hard to me to give any real debug of what happening, but it's not just me. anyone may be able to reproduce it. I know I re
  20. I am having severe hangs with firefox right now. it seems to happen on xfce, not on mate. I dont know why the syslog doesnt record anything beyond the boot procces. How to track whats going on guys?
  21. Hi guys! I asked a lot of devs about this feature and no one had the knowledge about this topic. I know it's something clearly missing on the kernel (display driver?). It's only available on very few boards right now, only RPI3 have it, not even RPI4 (but it's on developement or at least, heavily requested). you may know I am testing panfrost against tons of x86 games and bc we use hardware acceleretion, that capability is crucial to get enough gamma to actually play many games (unreal tournament, deus ex,etc). Ayufan told me I should ask on kodi team but I don't k
  22. threadX is a black box, and? I don't see a limitation on that. it would require just to use the official kernels by RPI foundation. that's all. I don't think it's sooo unachievable. @Igor is talented enough to achieve that.. I just want for Armbian a bit more founding. and people would prefer the reliability of ubuntu/debian with armbian tweaks. RPI4 struggle a lot on aarch64 and probably some of the armbian tweaks will make it a bit more reliable. I don't like RPI, but threadX is not the main issue. it's not an easy work, but not that hard neither, and th
  23. I know this topic was requested many many times. but I would like to introduce more reasons about why to do so. Igor, I don't like RPI, and many of you also don't like it. but I am thinking on Armbian rather than RPI 1) supporting RPI would be a plus for people that use sd with RPI4. armbian works flawlessly on sr cards. 2) armbian need recognition and founding and supporting a mainstream SBC like RPI could bring that! 3) armbian is the best OS for ARM Linux. 4) something similar to the reason 2
  24. Hi, this is a request...kinda, more like asking for help. A frined of mine have a PBP but his nvme draw tooo much battery. can we limit the speed of the nvme to save battery life. it would be handy also for servers that doesnt requiere that much write/read speeds and prefer power consumption rather than speed. maybe someone have an hdparm tip for that. thanks!!!
  25. no I will not loose time on that. this is for noobs, the pro knows how to make it. it's all open source. just compile everything hahaha we are making severe changes and those will appear sooner or later. this is our discord server if someone want to join https://discord.gg/buqfVHYTBA the idea it's to port our TwisterOS work, so move to xfce and redefine the build as TwisterOS Armbian.