Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<wpwrak> yeah, the spammers removed quite a few words from the written english language.
<arossDOTme> hmm the smaller posts ant got though yet. I guess I just wait.
freakazoid0223 has quit [Read error: Connection reset by peer]
xiangfu has joined #qi-hardware
heberth has quit [Read error: Connection reset by peer]
heberth has joined #qi-hardware
emeb has quit [Quit: Leaving.]
heberth has quit [Quit: leaving]
freakazoid0223 has joined #qi-hardware
<kristianpaul> ha nice wr703n was reversed eng
<kristianpaul> afaik not a free cad..
scientes has quit [*.net *.split]
scientes has joined #qi-hardware
nikescar has quit [Read error: Connection reset by peer]
nikescar has joined #qi-hardware
urandom__ has quit [Quit: Konversation terminated!]
<wolfspraul> kristianpaul: links?
DocScrutinizer05 has quit [Ping timeout: 240 seconds]
DocScrutinizer05 has joined #qi-hardware
scientes has quit [Read error: Connection reset by peer]
guanucoluis has joined #qi-hardware
<wolfspraul> he :-)
<wolfspraul> they worry whether it is 'legal' to do this. that discussion seems to be more important than this 'layout' only covering the top and bottom side and not the internal layers
<wolfspraul> urgh :-)
<wolfspraul> open hardware at its finest
guanucoluis has quit [Quit: Leaving.]
<wolfspraul> and then the non-functional 2-layer 'layout' is dumped into eagle
<wolfspraul> ha ha
<wolfspraul> painful stuff
<wolfspraul> I'm sure the industry is shivering in fear of that competitive threat there
<wolfspraul> it reminds me of some sloppily taken and blurred pictures of a pcb that some other project posted as proof of their 'openess' a while ago
<wolfspraul> they should take the whole pcb apart, photograph and enter into kicad/geda all layers, measure the values of all components and create an equivalent schematic
<wolfspraul> the they should proceed with a little 'couple hundred' test run to fix some bugs
<wolfspraul> and finally they could think about how to make money with an item that sells for 16 USD / pc, including box, case, usb cable, power adapter, etc. etc.
<wolfspraul> so looking at all this, I guess a quick couple-hour job dumping 2 layers into eagle and posting something is all we can and should expect
<wolfspraul> I'm curious how tp-link develops the sub-20 USD computer category that they have there...
<wolfspraul> I have a whole bunch of these 703n around me, as wifi repeaters and what not
arossDOTme has quit [Quit: Ex-Chat]
<roh> wolfspraul: how? copy-paste copy-paste copy-paste
<roh> ;)
<roh> and that done by people who can work for ridicilous low wages
<wpwrak> that's the fab. but behind that, you need some engineers who are very good. ultra-low price means huge volume. huge volume means very little room for errors.
<roh> wpwrak: thats what we think, from our pov. i guess there are different ones, else people wouldnt try to competen in 16E hw builing and sales
<roh> i know i dont. nothing to win there.
<wpwrak> why shouldn't they ? if they're good enough, and have access to the production capability (including ramp-up monay), they can pull it off.
<roh> wolfspraul: btw.. i did some 'powertools (vibration sander) and pcb tests... not as difficult as it sounds. atleast a 4layer board is a thing of one night and a bit of patience
<wpwrak> meanwhile, the giants are trying to kill each other in the high-end market ...
<roh> wpwrak: still its single euros per device. and huge risks. so from my pov its bad business.
<wpwrak> dinosaurs fighting dinosaurs, while the rodents happily evolve ahead :)
<roh> not that i dont like hw so cheap, but i cannot recommend anybody competing there
<wpwrak> we can't compete. but that doesn't mean that others have the same limitation.
<roh> wpwrak: may be. but thats not my concern then
<wolfspraul> let's see whether the market is big enough that qualcomm comes out with nice integrated follow-on chips for that segment
<wpwrak> it's probably just a question of having enough money at hand. if you can afford to produce 10M units before seeing any revenue, and the occasional mishap (oops, we just made one cubic kilometer of worthless trash) won't kill you, then you're big enough to play that game.
<wolfspraul> that's pretty much the only moving piece, and it would be nice if they would, no?
<wolfspraul> yeah the economics are pretty amazing if you really wrap your head around it
<wolfspraul> *selling* a whole computer with box, usb cable, power adapter, etc. etc. for 16 USD retail?
<wolfspraul> that's unbelievable really
<wolfspraul> even the tiniest expenses of 1 full-time engineer working on something for a while will need big big volume to be recouped
<wolfspraul> I hope they sell those thingies in the tens of millions and qualcomm can come out with improved chips, would be cool still
<wpwrak> hmm, i think all that only works at numbers where you can easily afford a bunch of really good engineers
<wolfspraul> the numbers are just amazing I think
<wolfspraul> it's under-appreciated as an economic achievement
<wolfspraul> try to buy an iron, and you will be hard pressed to find one below 20 USD
<wpwrak> yeah, a bit beyond our league. at least we understand enough of all that to be impressed :)
<wolfspraul> btw, fpgatools reached 20k lines of code today, phew :-)
<wolfspraul> towards the blinking led...
<wolfspraul> I hope this is all the right way to do it, but I can only try...
<wpwrak> damn. you beat fped (19.5 klocs)
<roh> hrhr
<roh> *sigh* quite depressing. i designed a series of devices lately and currently i can't even afford to prototype em
<roh> and thats simple crap. i got variants in dip and smd, and made a modular one last
<roh> could be sold as kit, but i need to invest a few hundred euro for parts and pcbs to be made and invest another bunch of time into software and finalisation of the mechanics/case
<roh> even to get that back the devices would need to be much more expensive that such a router, even if they are much simpler. sucks.
<roh> its a modular spdif routing/mux equipment which uses structured cat5 cabling as backend
rejon has quit [Remote host closed the connection]
LunaVorax has joined #qi-hardware
rejon has joined #qi-hardware
Jurting has quit [Remote host closed the connection]
LunaVorax has quit [Ping timeout: 260 seconds]
xiangfu has quit [Quit: Leaving]
xiangfu has joined #qi-hardware
jekhor has joined #qi-hardware
kristoffer has joined #qi-hardware
<kyak> xiangfu: hi, could we please catch up with the latest openwrt, there are several important commits there (which allow us to use gettext at it's power)?
jekhor has quit [Ping timeout: 255 seconds]
kristianpaul has quit [Ping timeout: 260 seconds]
kristianpaul has joined #qi-hardware
<qi-bot> [commit] nbd: lua: enable parallel builds (master) http://qi-hw.com/p/openwrt-xburst/4d84131
<qi-bot> [commit] florian: [package] base-files: skip LEDs handled by rssileds in led init-script (master) http://qi-hw.com/p/openwrt-xburst/8bbe39a
<qi-bot> [commit] florian: [ar7] generate vmlinux.srec and vmlinux.bin from srec2bin (master) http://qi-hw.com/p/openwrt-xburst/c8c0e0c
<qi-bot> [commit] kaloz: [cns3xxx]: fix non terminated uart resources for laguna (master) http://qi-hw.com/p/openwrt-xburst/6c1258a
<qi-bot> [commit] kaloz: The Gateworks System Controller (GSC) is an i2c device that provides system (master) http://qi-hw.com/p/openwrt-xburst/228bf4d
<qi-bot> [commit] kaloz: [cns3xxx]: fix (really this time) laguna UART config (master) http://qi-hw.com/p/openwrt-xburst/b2305bd
<qi-bot> [commit] Xiangfu Liu: uboot-xburst: update to 2010.06 (master) http://qi-hw.com/p/openwrt-xburst/a79283a
<qi-bot> [commit] Xiangfu Liu: uboot-xburst: enable-silent-console.patch (master) http://qi-hw.com/p/openwrt-xburst/33d9b4c
<qi-bot> [commit] Xiangfu Liu: uboot silent console (master) http://qi-hw.com/p/openwrt-xburst/0bc736c
<qi-bot> [commit] Xiangfu Liu: uboot-xburst: change load kernel size (master) http://qi-hw.com/p/openwrt-xburst/7e159dc
<qi-bot> [commit] Xiangfu: xburst: add WPAN support (master) http://qi-hw.com/p/openwrt-xburst/2ed90f6
<qi-bot> [commit] Xiangfu Liu: add WPAN(atben,atusb) kernel module file thansk blogic #qi-hardware @freenode.net (master) http://qi-hw.com/p/openwrt-xburst/32b4b06
<qi-bot> [commit] Xiangfu: xburst qi_lb60 disable WPAN kernel options, should build as module (master) http://qi-hw.com/p/openwrt-xburst/8040387
<qi-bot> [commit] Xiangfu: xburst: add Ben NanoNote kernel logo (master) http://qi-hw.com/p/openwrt-xburst/875b421
<qi-bot> [commit] Xiangfu: xburst: qi_lb60 select the nanonote slash screen (master) http://qi-hw.com/p/openwrt-xburst/07a3c5d
<qi-bot> [commit] Xiangfu: WPAN kernel module: make atusb depends on at86rf230 (master) http://qi-hw.com/p/openwrt-xburst/f6662d1
<qi-bot> [commit] Xiangfu: WPAN: fix atusb cannot build as module (master) http://qi-hw.com/p/openwrt-xburst/ce4eb6a
<qi-bot> [commit] Xiangfu: WPAN: wpan.mk: fix typo, add other IEE802154 device to WPAN subment (master) http://qi-hw.com/p/openwrt-xburst/381aece
<qi-bot> [commit] Xiangfu: xburst: ben nanonote: add modifire keys and fbcon-color patches (master) http://qi-hw.com/p/openwrt-xburst/a53d7e8
<qi-bot> [commit] Xiangfu: uboot-xburst: update to v2012.10-rc2 (master) http://qi-hw.com/p/openwrt-xburst/af862e9
<kyak> xiangfu: lot's of thanks
Jurting has joined #qi-hardware
jekhor has joined #qi-hardware
freakazoid0223 has quit [Ping timeout: 240 seconds]
<xiangfu> kyak, HI. I plan to release image soon. this week.
<xiangfu> kyak, thanks for the info. so I re-start the build after saw your message.
<kyak> do yo uplan to release with 3.6 kernel?
<xiangfu> kyak, no. the release build goes 2 steps. 1. build minimal. save all failed packages. 2. build full_system. dis-select all failed packages.
<xiangfu> kyak, (linux 3.6) no. I will follow the OpenWrt upstream. now the OpenWrt still 3.3
<xiangfu> kyak, the uboot is update to v2012.10, and fixed boot from memcard.
<kyak> that's good
<kyak> so let's see how many fallouts we got..
<kyak> i'm building the full image as well
<kyak> xiangfu: for xorg, i'm just reminding that you've disabled xorg feed completely from feeds.conf
<kyak> qt4 is in that feed.
<kyak> and gtk as well
jekhor has quit [Ping timeout: 260 seconds]
<xiangfu> if we disable the xorg feed. openwrt does not know there is qt libs etc.
<xiangfu> david's liballegro and emacs failed to build. :(
<kyak> strange
<xiangfu> oh.
<kyak> if qt4 failed, qt4 packages should have failed as well
<kyak> perhaps it's a false positive with qt4
<xiangfu> then I must make some mistake on copy feeds.conf to final folder.
<xiangfu> kyak, oh. sorry for confuse.
<xiangfu> kyak, I stop use that file for long time.
<xiangfu> kyak, I think we just drop it from openwrt-packages.
<xiangfu> kyak, since we already keep a correct file under "http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/'
<kyak> this makes sense.. need to correct http://en.qi-hardware.com/wiki/Building_Software_Image wiki page
<kyak> it refers to feeds.conf from openwrt-packages
<xiangfu> yes
<xiangfu> I plan to keep that in git history. but that do needs more time compare to keep it under downloads.qi-hardware.com
<qi-bot> [commit] Xiangfu: nanonote-files: remove outdate feeds.conf (master) http://qi-hw.com/p/openwrt-packages/54915fa
<xiangfu> yes.
<kyak> i updated the wiki
<xiangfu> kyak, great. thanks.
<kyak> xiangfu: how do you deselect failed packages? mark them as =m?
<kyak> ok
<xiangfu> the 'failed_packages.txt' created when compile openwrt minimal
<kyak> basically such approach should produce an empty failed_packages.txt at the end
<kyak> when all failed are marked as =m
<kyak> right?
<kyak> i'm asking because the final failed_packages.txt doesn't show ALL the failed packages
<xiangfu> no.
<xiangfu> if failed packages mark as =m. it still have 'failed build ....' in BUILD_LOG.
<xiangfu> it basically make the full_system compile smooth.
<kyak> have a look at NanoMap, tile, qball.. they are =m, but not exist in failed_packages
<kyak> though they definitely failed
<kyak> as they don't exist in packages/
<xiangfu> currect 'failed_packages.txt' not include all failed packages because the openwrt_minimal failed and exit build.
<xiangfu> this is because the 'qemu-host' failed to build. even if I mark it as 'm'. it still break the build.
<kyak> i'm talking about the release
<kyak> ah damn
<kyak> i need new eyes
<kyak> many failed packages, just as expected :) sorry for confusion
<xiangfu> yes. that build take my too much time. so I come with this auto mark failed package as modular. recently. :)
<kyak> that's good!
<xiangfu> this whole build take ~80 hours. :-) but it build smooth which is good.
<xiangfu> and I think I have a lot of 80 hours between release. :-)
<kyak> strange, now 'make' fails at 'make[3] -C target/linux compile'. When i re-run as 'make V=s', i'm presented with kernel config and then the build goes on
<kyak> running make kernel_menuconfig to update our config doesn't seem to help
<kyak> i never observed inconsistency between make and verbose make before
<kyak> perhaps kernel_menuconfig is not doing very godo job.. i'll try to add that option manually.. it asks about IEEE802154_6LOWPAN
<xiangfu> strange...
<kyak> after i added # CONFIG_IEEE802154_6LOWPAN is not set to target/linux/xburst/qi_lb60/config-3.3, everything works smooth
<kyak> i'm reluctant to commit this change before you have a look.. not sure if you observe this problem on your side
bzb has joined #qi-hardware
<xiangfu> kyak, please commit. this option should take care by package/kernel/modules/wpan.mk
<qi-bot> [commit] kyak: unset CONFIG_IEEE802154_6LOWPAN (master) http://qi-hw.com/p/openwrt-xburst/0c9426f
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
paul_boddie has joined #qi-hardware
<paul_boddie> Are Gtk+ and Qt actively maintained in OpenWrt? I can't say that I know how to do the git-related magic to pull in updates within the openwrt-nanonote build environment, but I didn't see much sign of activity on the various OpenWrt sites for those packages.
<xiangfu> kyak, let's wait the release build and test.
<xiangfu> paul_boddie, the gtk/qt is under 'svn://svn.openwrt.org/openwrt/feeds/xorg'
jluis|work has quit [Remote host closed the connection]
<xiangfu> mirko is maintain the qt. because I saw he is always try to fix qt build etc.
<paul_boddie> I can see that here: https://dev.openwrt.org/browser/feeds/xorg/lib/qt4
<paul_boddie> I tried to update gtk, but I got bogged down in the various rearchitecturing changes that project made as they moved towards 3.0.
<paul_boddie> Unless there's another repository, it seems to have stalled: https://dev.openwrt.org/browser/feeds/xorg/lib/gtk2
jekhor has joined #qi-hardware
<paul_boddie> If I could perform magic and make lots of time, I'd try and do a Debian-based equivalent software image, if only because of the active maintenance of such things in Debian and the use of things like glibc/eglibc which make some things easier.
<paul_boddie> Figuring out what the gtk maintainers were thinking and then patching their build systems is hard work!
<xiangfu> yes. agree
<paul_boddie> Maybe I can learn something from this... Loading a kernel module from a file descriptor: http://lwn.net/Articles/519009/
<kyak> paul_boddie: don't bother with gtk update, since it doesn't support DIrectFB
<kyak> the release we are usign now is probably the last one where DIrectFB works
<paul_boddie> kyak: I'm delegating all such matters to Debian at the moment, although I'm also not using gtk actively, anyway.
<kyak> do you run X?
jluis_ has quit [Ping timeout: 246 seconds]
jluis has joined #qi-hardware
<paul_boddie> No, just framebuffer stuff.
<paul_boddie> I wanted pygame support with numpy, but I may change my mind again at some point. But I doubt that X is likely to be an option.
guanucoluis1 has joined #qi-hardware
<paul_boddie> It's a shame Python uses 10MB of the RAM. Maybe it should go on a diet.
jluis has quit [Ping timeout: 246 seconds]
erikkugel has joined #qi-hardware
<kyak> if debian gtk packages run fine on framebuffer, perhaps we should have a look how it's done
<kyak> in DirectFB that is
<kyak> i once updated gtk2 from 2.17.0 (currently in Openwrt) to 2.24.4 only to see that DirectFB is broken
<kyak> i then read at their ML or somewhere else that it's not maintained anymore
<kyak> ..and then it is planned to drop it completely from gtk3
jluis has joined #qi-hardware
<kyak> not planned, already dropped
<kyak> everything is getting fat nowadays and needs a diet :)
<kyak> better stick with qt4.. its support for DirectFB is far more superior
<kyak> can even switch keyboard layouts
<kyak> and more apps (at least in qi-packages)
<kyak> btw, qt4 builds as i speak.. fingers crossed (maybe it was an intermittent problem on buildhost)
jluis has quit [Read error: Connection timed out]
heberth has joined #qi-hardware
<paul_boddie> It feels like all these projects are going backwards.
heberth has quit [Client Quit]
<kyak> if they continue going backwards they will end up running fine on a PC with 32 Mb RAM :)
kristoffer has quit [Quit: This computer has gone to sleep]
<paul_boddie> Sadly, they don't seem to go backwards in the resource usage department. I suppose the reason for not supporting the framebuffer any more is that we all have amazing 3D hardware now, or something.
xiangfu` has joined #qi-hardware
FrankBlues has joined #qi-hardware
<qi-bot> /msg xiangfu test
<qi-bot> /msg xiangfu tes
xiangfu` has left #qi-hardware [#qi-hardware]
bzb has quit [Quit: Leaving]
xiangfu has quit [Quit: Leaving]
<kyak> 'msg' implied :)
jekhor has quit [Ping timeout: 255 seconds]
kristoffer has joined #qi-hardware
urandom__ has joined #qi-hardware
<whitequark> paul_boddie: it actually makes sens
<whitequark> *sense
<whitequark> well, take for example wayland. it is a given fact that every desktop in last 10 years or so has at least Intel card, and that card is capable of compositing.
<whitequark> it is also a given fact that every Android smartphone since 3.0 has a mandatory GPU.
<whitequark> this comprises the overwhelming majority of systems where graphical Linux should run.
<whitequark> on the other hand, what Ubuntu does with Unity, well, just sucks
<whitequark> they are seemingly uncapable of programming
<paul_boddie> What doesn't make sense is the churn in the software stack. That's how we end up with desktop environments that are less functional than the ones they "replaced", and only after huge amounts of extra work and disruption.
<whitequark> yeah, let's stay with 1987's crap
<whitequark> bits do not rot; true. unfortunately, architecture of X11 has like nothing to do with the modern desktop. it's an obsolete abstraction.
<whitequark> take even network transparency. both gtk and qt in a network-transparent mode basically transfer pixmaps, which means that even VNC is more efficient, not even talking about a wayland network transport module (yet to be developed)
<whitequark> and per usage department... people like fast software, and so time-memory tradeoffs are almost always solved in the favor of time.
<whitequark> which unfortunately means that you spend limited resource (memory) instead of unlimited (cpu cycles)
erikkugel has quit [Quit: Leaving.]
erikkugel has joined #qi-hardware
<whitequark> paul_boddie: and if you're speaking about gtk3/gnome3, well, it was the reason I've switched to KDE.
<paul_boddie> Not everything in 1987 was crap, though. ;-)
<whitequark> paul_boddie: what wasn't? If we are talking about software.
<whitequark> I don't really see any piece of software from 1987 or its descendant which I would use except for compatibility
<whitequark> except, maybe, games. nethack is pretty cool.
<paul_boddie> Interesting question. I thought we were talking about hardware, but I'm pretty sure some essential software from 1987 is still around and isn't crap.
<whitequark> well, 1987 hw wasn't exactly bad per se, it was just not very developed
guanucoluis1 has quit [Read error: Connection reset by peer]
<whitequark> just as latest steam engines weren't crap
guanucoluis1 has joined #qi-hardware
<whitequark> emphasis on "latest". hardware went a very long way from those times, software is still commonly written in C with mostly same errors and patterns.
kristoffer has quit [Quit: This computer has gone to sleep]
<larsc> even C was crap back in 1987, at least by todays standards ;)
emeb has joined #qi-hardware
<kyak> if you look back, you might say, that, yeah, SW from 1987 is crap. But it wasn't crap back then. I don't like it that i feel like crap with 1Gb RAM, even running minimalistic Linux
<kyak> so the difference is that the today's SW is crap right now
<kyak> while you can only call the SW from 1987 crap after 20 years
<wpwrak> i daresay that sw from 1987 should be impressibly fast on today's hardware. around 1987 .. i think i had an ~8 MHz 8086-based PC with 640 kB of RAM (Amstrad PC-1512). floppy disks as mass storage. all that old sw would still run on my modern (just a few ywars old) PC, at several hundred times the speed. my floppy collection would comfortably fit in a RAM disk.
jluis has joined #qi-hardware
kristoffer has joined #qi-hardware
kristoffer has quit [Quit: This computer has gone to sleep]
paul_boddie has left #qi-hardware ["Kopete 0.11.3 : http://kopete.kde.org"]
<mth> wpwrak: there are a lot of good games from that era, but we emulate the old hardware rather than port the games
<mth> eh, I meant whitequark
<mth> should have typed two letters before tab...
<mth> porting wouldn't really be an option anyway, since most of the source code is proprietary, probably a lot of it is lost and a big portion was written in assembly rather than C
<mth> about X11: I ran a remote desktop for a few years at work, where I had to use Windows for company-issued applications but did all development in Linux
<mth> but I used NX rather than plain X11 because it performed better with KDE3
<mth> remote X works very well with applications from 15 years ago, but not so well with GTK/Qt since they introduced theming and gradients etc
<whitequark> indeed, and people want theming and gradients
<whitequark> honestly, I would _not_ want to work on a 15-year-old desktops. it wasn't minimalistic because that's better, it was minimalistic because hardware was stupid.
<whitequark> (apart from the fact that my main application runs in jvm and requies 1g+ to just start. it's a server one through, and that is well justified.)
<whitequark> *15-year-old apps for plain X, if you'd like.
<whitequark> wpwrak: it's indeed impressively fast, but is also very significantly featureless. e.g. C compilers.
<whitequark> you still have tcc which would perform amazingly on a 25-year-old hardware
<whitequark> but you also have "slow" and "bloated" LLVM which performs optimization better than humans do.
<whitequark> and, well, there is almost no problem fitting a modern _equivalent_ of 15-year-old software on a floppy disk
<whitequark> the problem is that people don't want an equivalent of black-and-white windows and dumb compilers and naive memory managers, they want more
<mth> I still want to write a Z80 backend for LLVM one day
<whitequark> heh
<wpwrak> hmm. i use fvwm as window manager. that one's about 18 years old, more than the 15 you find unacceptable. and it still serves me very well.
<mth> there are still people writing games for Z80 machines, but the C compilers they use are very poor at optimization
<mth> so they have to do all performance critical parts in asm
kristoffer has joined #qi-hardware
<mth> oh wow, I have to test that
<whitequark> wpwrak: does it have antialiased fonts, for example?
<whitequark> to be precise, Xft fonts.
<wpwrak> dunno. doesn't matter anyway. it's a window manager, not an e-book reader.
<whitequark> it's a perfect example of how X11 does not work. my notebook has a DPI of 170, and plain X fonts just don't work with it.
<whitequark> no.
<whitequark> if you cannot read a fucking window title, it does matter a lot.
<whitequark> I'm using i3wm, for that matter, and it is nowhere like bloated. I can't stand plasma.
<wpwrak> you mean 170 dpi is too low for your needs ?
<whitequark> wpwrak: why is it too low? it's near perfect
<wpwrak> you're saying that the low resolution forces you to use fonts that have less than, say, 5x7 pixels
<wpwrak> because at 5x7 and more, you don't need anti-aliasing
aisa has joined #qi-hardware
<whitequark> sorry, what? it's _high_ resolution. your monitor probably has 95 dpi or so.
<wpwrak> correct
<whitequark> old X font system simply won't draw letters which are big enough
<whitequark> apart from the fact that it doesn't know how to draw truetype fonts at all, and pixelated fonts aren't good.
<whitequark> I'm not talking about subpixel antialiasing (which I hate)
<whitequark> just the usual grayscale one
<wpwrak> my standard text font is 6x10, unaliased. it's very readable at 100 dpi.
<whitequark> your vision is probably much better than mine then.
<mth> eh, I prefer anti-aliasing on large font sizes, not on small ones
<whitequark> mth: I too
<whitequark> http://i.imgur.com/9qQqK.png < a screenshot
<mth> really small fonts have to be hand-optimized to be readable
<whitequark> mth: on my DPI I had to turn off hinting
<whitequark> it was making fonts significantly worse
<whitequark> srsly, once people see how do fonts look like on my display, they start saving money for the same notebook like I have.
<whitequark> and I mean that literally. well, at least in two cases.
<wpwrak> (vision) hmm, probably not. when wearing lenses, i'm having trouble to see fonts of that kind of size (6x10 or even 7x14) on my 211 dpi laptop. the joy of getting old ...
<whitequark> to be honest I've no idea how big my letters are in terms of pixels
<whitequark> it's 10pt
<wpwrak> if that screenshot is your normal environment, then they must be some 50 pixels tall. useful if you have very long arms, 10 m or so ;-)
<whitequark> wpwrak: indeed it is, let me get a photo of me working then
<mth> at least KDE understands that DPI is implied by the combination of screen size and resolution and is not a setting
<whitequark> mth: actually, I had to choose it as a setting in KDE
<mth> really? that's a regression then
<whitequark> might be. non-native resolutions on LCD displays are pointless anyway
<mth> ah, there is a "force fonts DPI" setting, but it's disabled on my PC
<kyak> whitequark: what's your notebook anyway?
<mth> I can imagine it's useful if you have bad eyesight and want larger fonts from web pages
<mth> but in theory it shouldn't be necessary for normal use
<whitequark> wpwrak: http://imgur.com/k38Nr should give you an idea of how it looks in real life
<whitequark> kyak: asus ux32vd. highly recommend as a linux machine for work. i7, discrete gpu, up to 10Gb RAM, very good quality.
<whitequark> mth: Chrome ignores it anyway, I had to set default scaling to 125%
<mth> but Chrome uses GTK, right? I think GTK does see DPI as a setting, which is plain wrong
<whitequark> mth: it's an open bug in Chrom[ium]
<whitequark> or rather in webkit
<kyak> whitequark: it's a good time, right now i'm looking for my home laptop replacement :)
<whitequark> mth: the point is, for two decades web designers thought that dpi==96.
<whitequark> and now if you just change the dpi in webkit, half of web breaks
<mth> yeah, I still have to tell people who write CSS that they should be using points rather than pixels except when dealing with bitmaps
<whitequark> bitmaps, ewww. blurred web is also a norm for me nowadays :/
<mth> well, if you have something like a screenshot, a bitmap is unavoidable
<whitequark> mth: for UI
<whitequark> e.g. gradients or buttons
<whitequark> especially icons on buttons
<whitequark> so awful
<mth> and unfortunately IE was very late with SVG support, so if you want fancy icons bitmaps are still the only real option
<kyak> whitequark: oh, 13.3" and Full HD? i currently have 15.6" and Full HD, and everything is pretty tiny (this is my WIndows machine at work)
<kyak> i was looking for something 17" :)
<whitequark> kyak: yeah, it's 13.3", Full HD _and_ IPS!
<kyak> what's IPS?
<whitequark> in-plane switching
<kyak> uh. let me google it for me :)
<whitequark> a technique of making LCD displays which makes white look like white and black like black
<whitequark> and not like some dim, boring crap
<mth> and it's got a much better viewing angle than TN panels do
<whitequark> yep, 178 of 180 degrees
<whitequark> i.e. any way you could want to look at it.
<kyak> yeah, i'm thinkinh about it
<mth> I got an S-PVA monitor for my desktop, that also has a good viewing angle
<kyak> i was not considering anything below 15", so this laptop didn't catchmy attention..
<mth> I really dislike it when colors change if you tilt your head a bit
<whitequark> mth: especially if the most convenient looking angle does not match with the optimal LCD viewing angle
<whitequark> annoying like hell
<mth> with a laptop that often happens, with a desktop it's not so common
<whitequark> yes
<mth> but a desktop monitor is larger, so you are looking at sharper angles more often
<mth> put an even color on the desktop background on a large TN panel and you'll see a gradient
<whitequark> well I don't generally collect posessions of significant size. I like it if I can just pack all my stuff in a single backpack and go somewhere. so... no desktops as you can guess
<mth> I'm pretty much the opposite, I only travel if I really want to be in some other place
<whitequark> mth: I don't generally travel much
<whitequark> rather the opposite
<whitequark> I just like that I can do that.
<mth> ah ok
<whitequark> reduces amount of cruft in the place where you live, forces you to optimize consumption
<whitequark> etc
<mth> I don't like to throw away stuff that still works, so I've got quite a lot of old hardware around
<wpwrak> whitequark: seems excessively huge. but well, maybe when i hit 60, i'll appreciate such sizes too... :)
<whitequark> mth: I don't either, I give it away to those who need it
<wpwrak> btw, white on black may help. allows the eye to use a smaller aperture, which increases the field of vision
<mth> it's not huge at 170 dpi though
<whitequark> wpwrak: hm. seems pretty normal to me.
<whitequark> not really significantly bigger than on my previous notebook with an ordinary display
<wpwrak> that's a good trick to know when suffering age-related farsightedness
<whitequark> wpwrak: (white on black) I hate that combination. It always happens that I open the lid at night and, ow, my eyes are in pain
<wpwrak> (not specifically for displays but for any reading/viewing situation)
<mth> whitequark: I give away my old PCs, but I like to keep old game consoles around in case I want to play old games again
<wpwrak> whitequark: that's what you get for trying to work before the hangover has subsided ;-)
<whitequark> wpwrak: hahaha
<kyak> whitequark: i'm looking more into this beast: http://market.yandex.ru/model.xml?modelid=7795517 :)
<kristianpaul> the only think i look when i buy a computer is display actually, if it reads ok no much bright and high resolution in small package is a way to go for me
jekhor has joined #qi-hardware
<kyak> mirko: a bunch of qt4 packages result in the following error: Package qt4-drivers-gfx-directfb is missing dependencies for the following libraries: libQtGui.so.4 libQtNetwork.so.4
<kyak> apart from qt4-drivers-gfx-directfb these are *mouse drivers and qt4-mysql (missing libmysql_r)
<kyak> adding +qt4-gui and +qt4-network in DEPENDS for these packages yeilds strange results - these entries dissappear from .config
<kyak> adding +PACKAGE_qt4-mysql:libmysqlclient-r to qt4-mysql DEPENDS solved the problem for qt4-mysql.. But for other packages, the situation seems different
<kyak> i guess there is some cyclic dependency with qt4-gui and qt4-network
lekernel has quit [Ping timeout: 245 seconds]
lekernel has joined #qi-hardware
kristoffer has quit [Quit: This computer has gone to sleep]
kristoffer has joined #qi-hardware
kristoffer has quit [Client Quit]
GNUtoo-desktop has joined #qi-hardware
<kyak> mirko: running with the following patch now: https://gist.github.com/3874950 . Hope it helps, trial-and-error iterations over qt4 take so long
<FrankBlues> :D
<FrankBlues> Ack, wrong window, heh
LunaVorax has joined #qi-hardware
Sucotronic has joined #qi-hardware
wolfspraul has quit [Ping timeout: 260 seconds]
wolfspraul has joined #qi-hardware
pcercuei has joined #qi-hardware
pcercuei2 has joined #qi-hardware
pcercuei has quit [Read error: Connection reset by peer]
porchao has joined #qi-hardware
porchaso0 has quit [Ping timeout: 240 seconds]
Sucotronic has quit [Read error: Connection reset by peer]
Sucotronic has joined #qi-hardware
GNUtoo-desktop has quit [Quit: [INFO] fsogsmd : received signal -11, exiting.]
dandon has quit [Ping timeout: 256 seconds]
dandon has joined #qi-hardware
Sucotronic has quit [Quit: Bye]
erikkugel has quit [Quit: Leaving.]
guanucoluis1 has quit [Read error: Connection reset by peer]
heberth has joined #qi-hardware
pcercuei2 has quit [Ping timeout: 246 seconds]
freemor has joined #qi-hardware
freemor has left #qi-hardware [#qi-hardware]
scientes has joined #qi-hardware
jekhor has quit [Ping timeout: 246 seconds]
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 252 seconds]
dandon_ is now known as dandon
LunaVorax has quit [Ping timeout: 240 seconds]
aisa has quit [Quit: leaving]
<qi-bot> [commit] Marcos Paulo de Souza: media/radio/radio-rda5807.c: Use devm_* when allocating memory (jz-3.6) http://qi-hw.com/p/qi-kernel/dbd96db
<qi-bot> [commit] Marcos Paulo de Souza: media/radio/radio-rda5807: Use module_i2c_driver instead of module_{init|exit} (jz-3.6) http://qi-hw.com/p/qi-kernel/a96c584
<qi-bot> [commit] Marcos Paulo de Souza: media/radio/radio-rda5807.c: Wait for seek complete before return (jz-3.6) http://qi-hw.com/p/qi-kernel/7b4d427
FrankBlues has quit [Quit: Leaving]
heberth has quit [Quit: leaving]
wolfspraul has quit [Ping timeout: 248 seconds]
wolfspraul has joined #qi-hardware