Re: Documentation for Realtek 8188* devices
On Nov 14, 2013 7:30 PM, Dmitrij D. Czarkoff czark...@gmail.com wrote: Hello! I'm strugling to find any documentation for RTL8188* wireless devices (including those already supported in urtwn driver). I wrote to Realtek, but no responce followed. My problem is that I have a MiniPCI RTL8188CE device in my ThinkPad, and I want to try writing a driver for it. AFAIK RTL8188CE-VAU (supported in urtwn) is essencially RTL8188CE with USB bridge, so having access to documentation urtwn driver was based on would be very helpful. So, if anyone knows where these docs can be found, I would be very greatful. -- Dmitrij D. Czarkoff Hi Dmitrij, Wishing you the best finding documentation and receiving a response from Realtek. It is safe to say the latter has become my hobby... Not of preference but of perseverance. Anyway, I've picked up FreeBSD Device Drivers (Kong) which seems like an okay, albeit rough, place to start understanding drivers for OpenBSD (only real driver reference out there besides the tree), though adding support for the PCIe Mini routine of your device shouldn't be the most difficult feat ever, the cousin chip is already supported. Check out how other cards (iwn(4)) attach. I've an RTL8723AS-VAU which is reportedly a non-mass production analog to the 8192CU (also urtwn), except with a BT function. There is even a `urtwn-rtl8723fw' that comes with urtwn but no documentation on those magic numbers `8723'. We're on similar boats/rafts. Please post back your findings. Would be interested in helping you so as to help myself and others. Cheers.
Re: wifi 5.4
Hi, I have Realtek 8188CE connected via PCI in my laptop. The 8188CE driver (urtwn) is USB only. So I decided to buy USB WiFi. I've got 2 realtek based and one Realtek 8188EU, one Ralink 5372 and one Atheros AR9271. The first two aren't recognised, the last one hang network after ten minutes of work. See urtwn(4) for the list of supported adapters. If/when your network hangs, run `sh /etc/netstart' to restart it. If it is too hard to make any usb wifi work, does anybody have mini pci-e wifi working? I can try to buy another wifi module. Many USB adapters have been working for a long time in OpenBSD. I can't say for PCIe, however many `modern' adapters, like the Airlink101 AWLL5088, are easily bought for $15.
Re: Sorry OpenBSD people, been a bit busy
On Sun, Oct 6, 2013 at 8:48 PM, dera...@cvs.openbsd.org wrote: Hi, yeah, it is really me. I find it strange posting to misc, starting an email thread. Normally I finish the threads here. Most OpenBSD developers have known for a while, but I think it is important to tell the greater community that I've been a bit busy for about the last year. I have not been paying as much attention to OpenBSD development as I'm expected to. Luckily, other developers have done a great job keeping it on track. Why? With a group of others, I started setting up an Internet Exchange in Calgary, and this has taken much time because it is highly politicized and has encountered some resistance. http://yycix.ca https://en.wikipedia.org/wiki/YYCIX_Internet_Exchange_Community_Ltd Now, why do I mention this in relation to OpenBSD? Well, at the end of 2007 someone decided to open an impersonation account on twitter in my name, and start sending a mix of things I have said (see wikiquote for instance), with things that I would never say. That account is http://twitter.com/theoderaadt A few notes: The account has now changed to declare that it is a parody account and renamed to Not Theo de Raadt, as of a few days ago. If you read back into the past, you will see true character of the account and the individual. People in the local community were directed to the account, to give a negative, if not slanderous, view of my character. The ones directing them have high-profile roles in the community, so people would take what they say as true. Since I am the network manager for the exchange equipment, this by extension was meant to hurt YYCIX. Why would stewards of important infrastructure projects deliberately spread such false stories? I will not mention names. I don't need to; many can dig a little and figure out who those actors are. As a hint, search a little bit higher. Finally, one thing that particularily bothers me in the old postings is the mention of my old friend Itojun, a very dedicated developer of IPv6. As many of you know, he and John Postel are the only two internet architects currently honoured on an annual basis by the Internet Society in the form of an award. http://www.internetsociety.org/what-we-do/grants-and-awards/awards/itojun-service-award Layers of hurt being thrown around. Why? People are people, that's why. Keep up the good philanthropic work and don't let the long faces get you down.
Re: Backlight on lenovo ideapad
hw.sensors.cpu0.temp0=47.00 degC hw.sensors.acpitz0.temp0=52.00 degC (zone temperature) hw.sensors.acpibat0.volt0=14.80 VDC (voltage) hw.sensors.acpibat0.volt1=16.18 VDC (current voltage) hw.sensors.acpibat0.power0=0.00 W (rate) hw.sensors.acpibat0.watthour0=46.15 Wh (last full capacity) hw.sensors.acpibat0.watthour1=4.62 Wh (warning capacity) hw.sensors.acpibat0.watthour2=2.31 Wh (low capacity) hw.sensors.acpibat0.watthour3=45.69 Wh (remaining capacity), OK hw.sensors.acpibat0.raw0=0 (battery idle), OK hw.sensors.acpiac0.indicator0=On (power supply) hw.sensors.acpibtn0.indicator0=Off (lid open) hw.cpuspeed=774 hw.setperf=0 hw.vendor=LENOVO hw.product=20175 hw.version=Lenovo IdeaPad Yoga 13 hw.serialno=1 hw.uuid=1 hw.physmem=8450203648 hw.usermem=8427495424 hw.ncpufound=4 hw.allowpowerdown=1 machdep.console_device=ttyC0 machdep.bios.diskinfo.128=bootdev = 0xa0010204, cylinders = 1023, heads = 255, sectors = 63 machdep.bios.diskinfo.129=bootdev = 0xa204, cylinders = 1023, heads = 255, sectors = 63 machdep.bios.cksumlen=1 machdep.allowaperture=2 machdep.cpuvendor=GenuineIntel machdep.cpuid=198313 machdep.cpufeature=-1074004993 machdep.kbdreset=0 machdep.xcrypt=0 machdep.lidsuspend=0 ddb.radix=16 ddb.max_width=80 ddb.max_line=24 ddb.tab_stop_width=8 ddb.panic=1 ddb.console=0 ddb.log=1 ddb.trigger=0 vfs.mounts.ffs has 9 mounted instances vfs.ffs.doclusterread=1 vfs.ffs.doclusterwrite=1 vfs.ffs.doreallocblks=1 vfs.ffs.doasyncfree=1 vfs.ffs.max_softdeps=23704 vfs.ffs.sd_tickdelay=2 vfs.ffs.sd_worklist_push=0 vfs.ffs.sd_blk_limit_push=0 vfs.ffs.sd_ino_limit_push=0 vfs.ffs.sd_blk_limit_hit=0 vfs.ffs.sd_ino_limit_hit=0 vfs.ffs.sd_sync_limit_hit=0 vfs.ffs.sd_indir_blk_ptrs=0 vfs.ffs.sd_inode_bitmap=0 vfs.ffs.sd_direct_blk_ptrs=0 vfs.ffs.sd_dir_entry=0 vfs.ffs.dirhash_dirsize=2560 vfs.ffs.dirhash_maxmem=2097152 vfs.ffs.dirhash_mem=334375 vfs.nfs.iothreads=-1 On Sun, Oct 6, 2013 at 12:42 AM, Tomas Bodzar tomas.bod...@gmail.comwrote: On Thu, Oct 3, 2013 at 1:28 AM, Jean Lucas nos...@gmail.com wrote: Hello, Is there a parallel for /sys/class/backlight, which under Linux would return the 2 backlight controllers in my machine (acpi_video0 and intel_backlight), for OpenBSD? Changing the backlight option in xorg.conf to intel_backlight doesn't do the trick. Man pages are welcomed. Post your dmesg output and sysctl output to see what's in your laptop ;-)
Re: USB ethernet for OpenBSD
Look for something with no drivers CD... I had luck with a plain Belkin USB to Ethernet adapter with no specs on the package and a Mac OS Universal logo on it, works with axe(4), $30. Good luck. On Oct 2, 2013 3:51 PM, obsd, cgi obsd...@postafiok.hu wrote: Hi! Can someone please mention a working USB to Ethernet adapter for OpenBSD 5.3? (anybody has a working one and can share the name of it?) It doesn't need to be Gbit big... just a 10/100 would be more then enough.. +1 if it could be buyed from: http://www.ebay.co.uk/ Many Thanks, have a nice day!
Re: USB ethernet for OpenBSD
No! I was fixing to relate a recent tragic but happy ending story about these... I had a friend buy one of the supposed cheapo blue ones (at a premium price), turns out it was a knock off that reportedly barely works (crawls) with the drivers for windoz (only) it comes with. Make sure and buy from a manufacturer that supports generic drivers.
Backlight on lenovo ideapad
Hello, Is there a parallel for /sys/class/backlight, which under Linux would return the 2 backlight controllers in my machine (acpi_video0 and intel_backlight), for OpenBSD? Changing the backlight option in xorg.conf to intel_backlight doesn't do the trick. Man pages are welcomed.
Re: USB ethernet for OpenBSD
Oh the happy ending to this story was he returned it and got that premium payment back. Fairy tales. On Oct 2, 2013 7:19 PM, Jean Lucas nos...@gmail.com wrote: No! I was fixing to relate a recent tragic but happy ending story about these... I had a friend buy one of the supposed cheapo blue ones (at a premium price), turns out it was a knock off that reportedly barely works (crawls) with the drivers for windoz (only) it comes with. Make sure and buy from a manufacturer that supports generic drivers.
Re: Hard Freeze with Snapshots After Aug 19 on ThinkPad X1 Carbon
With and without in my case. Its frustrating, even with suspend/resume partially working (touchscreen screws up afterwards), the console will still freeze after some time, so the system is not dependable. On Aug 31, 2013 10:10 AM, ... merlyn...@gmail.com wrote: Do you experience hard lock with X or without X? If only with X, it could be similar to my problem with Xorg acpilk-ed process... On 31 August 2013 01:29, Bryan Vyhmeister br...@bsdjournal.net wrote: On Aug 30, 2013, at 12:43, Jean Lucas nos...@gmail.com wrote: Yes, on an IdeaPad Yoga 13 I also experience hard freezes throughout the day. The timing varies from as little as one hour to several. Started happening a few snapshots back (around Aug. 19). Maybe ThinkPad ACPI related or something like that? Anyone have any ideas what might be causing the hard freezes? I haven't tried on my ThinkPad X230 but I could test on it as well if needed. Bryan
Re: Hard Freeze with Snapshots After Aug 19 on ThinkPad X1 Carbon
Yes, on an IdeaPad Yoga 13 I also experience hard freezes throughout the day. The timing varies from as little as one hour to several. Started happening a few snapshots back (around Aug. 19). On Aug 30, 2013 11:02 AM, Bryan Vyhmeister br...@bsdjournal.net wrote: I'm running OpenBSD/amd64 5.4-current with GENERIC.MP from 2013/08/19 downloaded from the mirrors on a Levovo ThinkPad X1 Carbon. Both snapshots I have tried (2013/08/25 and 2013/08/29) after the 19th have resulted in hard system freezes every few hours. I don't have any logs or anything else that indicate a hard freeze but everything just hard freezes. I first noticed because I left the ThinkPad running overnight on my desk and when I came back to the system the next morning it was hard frozen. Several times during the day while I'm working I have also experienced the same thing. Anyone else seeing something similar? Bryan
Re: Issue: pkg_add gettext-0.18.2p1
On 07/05/2013 11:14 AM, MK2 wrote: # pkg_add http://ftp.openbsd.org/pub/OpenBSD/5.3/packages/ amd64/gettext-0.18.2p1.tgz Fatal error: Ustar [http://ftp.openbsd.org/pub/OpenBSD/5.3/packages/ amd64/gettext-0.18.2p1.tgz][share/locale/zh_TW/LC_MESSAGES/ gettext-tools.mo]: Premature end of archive Adjusting sha for /usr/local/share/locale/zh_TW/LC_MESSAGES/ gettext-tools.mo from u1Zb6iQbP0lQDC/MvuxOekHKTs470zwHLDJBzvItNjc= to FF9+wEW+LROgonlt3qJWeHT+fvcXX+ehwx+Rc1CBlfA= Fatal error: Installation of gettext-0.18.2p1 failed, partial installation recorded as partial-gettext-0.18.2p1 at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 808 # pkg_info joe-3.7p1 Joe's Own Editor libiconv-1.14p0 character set conversion library partial-gettext-0.18.2p1 GNU gettext # uname -rsm OpenBSD 5.3 amd64 This is a nice email. A bunch of text with no real purpose. Did you define PKG_CACHE and not make the directory?
Re: Issue: pkg_add gettext-0.18.2p1
On 07/05/2013 12:34 PM, MK2 wrote: Jean Lucas wrote: On 07/05/2013 11:14 AM, MK2 wrote: # pkg_add http://ftp.openbsd.org/pub/OpenBSD/5.3/packages/ amd64/gettext-0.18.2p1.tgz Fatal error: Ustar [http://ftp.openbsd.org/pub/OpenBSD/5.3/packages/ amd64/gettext-0.18.2p1.tgz][share/locale/zh_TW/LC_MESSAGES/ gettext-tools.mo]: Premature end of archive Adjusting sha for /usr/local/share/locale/zh_TW/LC_MESSAGES/ gettext-tools.mo from u1Zb6iQbP0lQDC/MvuxOekHKTs470zwHLDJBzvItNjc= to FF9+wEW+LROgonlt3qJWeHT+fvcXX+ehwx+Rc1CBlfA= Fatal error: Installation of gettext-0.18.2p1 failed, partial installation recorded as partial-gettext-0.18.2p1 at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 808 # pkg_info joe-3.7p1 Joe's Own Editor libiconv-1.14p0 character set conversion library partial-gettext-0.18.2p1 GNU gettext # uname -rsm OpenBSD 5.3 amd64 This is a nice email. A bunch of text with no real purpose. Did you define PKG_CACHE and not make the directory? Hi Jean, tried mkdir /root/pkg and prepended env PKG_CACHE=/root/pkg to my pkg_add(above) but same error. Also, I just tried downloading the package with lynx and doing pkg_add on the file name, but also get the error. Regards MK. PS- sorry for the ugly text Are you running lynx as root? Bad idea. But if you're not, this is why you can't access the file, or lynx is not even saving it to the root directory. Try using the mirror closest to you for starters. Use a non-privileged user + sudo for pkg_add. Issue `export PKG_CACHE=/home/foo/cache', make this directory, ensure you have permissions for it, then try adding the package again.
Shutdown procedure
Hi all, I've a Dell Studio Hybrid 140g running July 2nd's amd64 snapshot. When I reboot/shutdown, on startup, the first stage loader doesn't load. The machine is stuck, and I think it's because of the shutdown procedure in OpenBSD and acpi compatibility with this machine. The problem has been isolated to the OS for various reasons - the DVD drive (slot loader, which 'ejects' every 3 seconds when the machines sticks after reboot/shutdown, forever) was removed, the hard drive was also removed, and the same snapshot was run from a flash drive, with the same effect on the machine. I've also tried 5.3 Release, and snapshots May 7th, May 20th, and June 7th (because I swore one of my 50 snapshot's reboot worked fine). When Linux reboots on this machine, there is a noticeable 3 seconds of power down, the power light turns off, then it starts up okay. When OpenBSD shuts down, the computer remains on after shutdown, and seems to struggle when it starts back up; only a flashing cursor after POST - this is the error. This is a trace of procedure calls from kernel and memory images after rebooting with the dump option: #0 0x8137b604 in dumpsys () #1 0x8137b755 in boot () #2 0x81203f9e in sys_reboot () #3 0x81384959 in syscall () #4 0x81000907 in Xsyscall () And here some relevant bits: OpenBSD 5.3-current (GENERIC.MP) #12: Tue Jul 2 12:31:13 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4269342720 (4071MB) avail mem = 4147961856 (3955MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfcbc0 (50 entries) bios0: vendor Dell Inc. version 1.1.0 date 11/09/2009 bios0: Dell Inc. Studio Hybrid 140g acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIC HPET GSCI SSDT acpi0: wakeup devices P0P2(S4) P0P1(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) GBEC(S4) P0P8(S4) P0P9(S4) HDAC(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 3511.51 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz, 2194.50 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 1 (P0P1) acpiprt3 at acpi0: bus 4 (P0P4) acpiprt4 at acpi0: bus -1 (P0P5) acpiprt5 at acpi0: bus 3 (P0P6) acpiprt6 at acpi0: bus 2 (P0P7) acpiprt7 at acpi0: bus -1 (P0P8) acpiprt8 at acpi0: bus -1 (P0P9) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpibtn0 at acpi0: PWRB Thanks.
Working on suspend/resume
Hi all, How does one begin diagnosing sleep/suspend for a particular machine? In this case, a Lenovo Yoga 13. The ACPI states are frozen (frozen battery meter and lying reports about my AC adapter being plugged in when it's not). If someone could help me add signals for my machine, it'd be easier to work on other problems without restarting all the time and/or shutting down for overheating purposes. Installed FreeBSD to see if suspend/resume worked; telling sysctl that the lid switch state is S3 worked, and successfully suspended. Resuming was an entirely different issue. Adding the reset video parameter, however, booted me into my first operating system on resume. Weird. hw.acpi.lid_switch_state=s3 hw.acpi.reset_video=1 (http://forums.freebsd.org/showthread.php?t=6942) Thanks, Jean
Re: Working on suspend/resume
Theo, Thanks for the info, very much appreciated! Theo de Raadt dera...@cvs.openbsd.org wrote: How does one begin diagnosing sleep/suspend for a particular machine? In this case, a Lenovo Yoga 13. The ACPI states are frozen (frozen battery meter and lying reports about my AC adapter being plugged in when it's not). If someone could help me add signals for my machine, it'd be easier to work on other problems without restarting all the time and/or shutting down for overheating purposes. I thikn your laptop is one of those relying on something we still don't do, which is the processing of acpipwrres _ON and _OFF events. There is some effort to get that supported. Installed FreeBSD to see if suspend/resume worked; telling sysctl that the lid switch state is S3 worked, and successfully suspended. Resuming was an entirely different issue. Adding the reset video parameter, however, booted me into my first operating system on resume. Weird. hw.acpi.lid_switch_state=s3 hw.acpi.reset_video=1 (http://forums.freebsd.org/showthread.php?t=6942) Discussing freebsd to us doesn't make you any real friends. Anyways, their suspend/resume isn't even something they try hard at. They have simply failed to put as much effort into suspend/resume. We've put thousands of manhours in, and it's pretty good, except for corner case laptops which require some rarely used part of the specification.. Look for commits in the next few months that talk about power management resources.
HD4000 problems
I've an (Intel) HD4000 and from the point that inteldrm was added to current, X freezes on launch, and have to SSH in to reboot nicely. Read a post with a similar problem; reducing video memory to 128 MB was the trick to have X start on current. I'm running yesterdays (20th May) -current, on a Lenovo Yoga 13, and there is no option for video memory in the BIOS. For 5.3 release however, X starts when I disable DPTF ( Intel dynamic platform thermal framework). 5.2 release worked fine with this enabled. Question: is there a kernel option to reduce video memory used by the OS to see if the workaround is valid? Back to the point, X -configure returns a Segmentation fault 0x28, and when just running startx, Xorg.0.log reveals Output LVDS1 has no monitor section. (Note: 5.2 5.3 release returned same segfault, though X worked flawlessly with startx) A few snapshots back, X would start after booting single-user and rebooting, though failure-success rate was around 4:1. When it would start, running xbacklight would freeze X again. Also idling too long would cause X to freeze. Files attached: X -configure and startx logs, and pcidump Best, Jean [demime 1.01d removed an attachment of type application/x-gtar which had a name of yoga.tgz]
Re: HD4000 problems
Well sending an archive to misc is just silly... http://filebin.ca/htF9pCQ6fHD/yoga.tgz Jean Lucas horsef...@lavabit.com wrote: I've an (Intel) HD4000 and from the point that inteldrm was added to current, X freezes on launch, and have to SSH in to reboot nicely. Read a post with a similar problem; reducing video memory to 128 MB was the trick to have X start on current. I'm running yesterdays (20th May) -current, on a Lenovo Yoga 13, and there is no option for video memory in the BIOS. For 5.3 release however, X starts when I disable DPTF ( Intel dynamic platform thermal framework). 5.2 release worked fine with this enabled. Question: is there a kernel option to reduce video memory used by the OS to see if the workaround is valid? Back to the point, X -configure returns a Segmentation fault 0x28, and when just running startx, Xorg.0.log reveals Output LVDS1 has no monitor section. (Note: 5.2 5.3 release returned same segfault, though X worked flawlessly with startx) A few snapshots back, X would start after booting single-user and rebooting, though failure-success rate was around 4:1. When it would start, running xbacklight would freeze X again. Also idling too long would cause X to freeze. Files attached: X -configure and startx logs, and pcidump Best, Jean [demime 1.01d removed an attachment of type application/x-gtar which had a name of yoga.tgz]
Porting RTL8723AU
https://github.com/lwfinger/rtl8723au I don't write drivers yet, and only now am beginning to tinker with the kernel. The repo has a linux (sic) driver for the dreaded wifi+BT RTL8723AU-VAS (wifi only, BT is the same address + _bt) card found in the Lenovo Yoga 13 and others. If someone can help me port the driver, that'd be wonderful.
Re: Porting RTL8723AU
On 05/20/2013 09:58 AM, Baurzhan Muftakhidinov wrote: On Mon, May 20, 2013 at 7:30 PM, Jean Lucas horsef...@lavabit.com wrote: https://github.com/lwfinger/rtl8723au I don't write drivers yet, and only now am beginning to tinker with the kernel. The repo has a linux (sic) driver for the dreaded wifi+BT RTL8723AU-VAS (wifi only, BT is the same address + _bt) card found in the Lenovo Yoga 13 and others. If someone can help me port the driver, that'd be wonderful. You didn't specify the license GPLv2. One for all, all for one. P.S. Sorry Baurzhan, forgot to CC.
Re: Porting RTL8723AU
Is one able to strip the GPL from a repo? In the case of this repo, would the driver have to be completely reconstructed/reimplemented in the case the GPL could not be stripped? As far as the end result goes, be that engineering a new driver or if one can strip the GPL from the existing repo, the new driver would/could be BSD licensed, if that decision were up to me. Philip Guenther guent...@gmail.com wrote: On Mon, May 20, 2013 at 8:49 AM, Jean Lucas horsef...@lavabit.com wrote: On 05/20/2013 09:58 AM, Baurzhan Muftakhidinov wrote: ... You didn't specify the license GPLv2. One for all, all for one.GNU General Public License, GPL, LGPL, copyleft, etc. You should carefully review http://www.openbsd.org/policy.html To quote from it: -- The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code. While this may be a noble strategy in terms of software sharing, it is a condition that is typically unacceptable for commercial use of software. As a consequence, software bound by the GPL terms can not be included in the kernel or runtime of OpenBSD, though software subject to GPL terms may be included as development tools or as part of the system that are optional as long as such use does not result in OpenBSD as a whole becoming subject to the GPL terms. -- So, if you decide to license your driver under any version of the GPL, it will not become an official part of OpenBSD as long as it has that license. Philip Guenther
Re: Porting RTL8723AU
Realtek has no official software distribution on their site of a RTL8723 driver. As far as the repo goes, it was highly likely taken from a beta-grade (at best) Dropbox'ed linux driver posted on ubuntu sites after popular demand. The fact that, in the repo, pieces of code with text saying Copyright Realtek and GPLv2, means that it could not be ported? Reiterating, could the GPLv2 bits be removed when the driver is ported to BSD with a valid license? Jean Lucas horsef...@lavabit.com wrote: Is one able to strip the GPL from a repo? In the case of this repo, would the driver have to be completely reconstructed/reimplemented in the case the GPL could not be stripped? As far as the end result goes, be that engineering a new driver or if one can strip the GPL from the existing repo, the new driver would/could be BSD licensed, if that decision were up to me.
Re: Porting RTL8723AU
In conclusion, reverse engineering is the only option for support. Since using this repo to port/construct a new driver would constitute a derivative work, and stripping licenses is bad, one has to reinvent the wheel. Or get realtek to issue a BSD-licensed driver. Brian Callahan bcal...@devio.us wrote: On 5/20/2013 2:14 PM, Jean Lucas wrote: Is one able to strip the GPL from a repo? In the case of this repo, would the driver have to be completely reconstructed/reimplemented in the case the GPL could not be stripped? As far as the end result goes, be that engineering a new driver or if one can strip the GPL from the existing repo, the new driver would/could be BSD licensed, if that decision were up to me. What does that mean strip the GPL from a repo? As in, hey, I know you licensed this driver under the GPL but I don't care I'm gonna relicense it, in violation of the GPL? Philip Guenther guent...@gmail.com wrote: On Mon, May 20, 2013 at 8:49 AM, Jean Lucas horsef...@lavabit.com wrote: On 05/20/2013 09:58 AM, Baurzhan Muftakhidinov wrote: ... You didn't specify the license GPLv2. One for all, all for one.GNU General Public License, GPL, LGPL, copyleft, etc. You should carefully review http://www.openbsd.org/policy.html To quote from it: -- The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code. While this may be a noble strategy in terms of software sharing, it is a condition that is typically unacceptable for commercial use of software. As a consequence, software bound by the GPL terms can not be included in the kernel or runtime of OpenBSD, though software subject to GPL terms may be included as development tools or as part of the system that are optional as long as such use does not result in OpenBSD as a whole becoming subject to the GPL terms. -- So, if you decide to license your driver under any version of the GPL, it will not become an official part of OpenBSD as long as it has that license. Philip Guenther
Re: Porting RTL8723AU
Great pointers. Will check out the existing urtwn driver (I believe thats the Realtek driver; the Yoga laptop has touchscreen, apm, acpi, bios/uefi issues as well just to name a few!) and see if I pick up some techniques. Will also contact realtek if they're willing to provide something and post back results whatever they may be. Cheers. Stefan Sperling s...@openbsd.org wrote: On Mon, May 20, 2013 at 02:36:16PM -0400, Jean Lucas wrote: In conclusion, reverse engineering is the only option for support. Since using this repo to port/construct a new driver would constitute a derivative work, and stripping licenses is bad, one has to reinvent the wheel. Copyright covers specific expressions (implementations) of a work (a driver for this device). Copyright for one driver doesn't cover other implementations of drivers for the same device (the copyright holder would need a patent for that kind of protection). I believe it is OK to use an existing GPL driver as a documentation reference, and write a new driver from scratch based on that information. However, it is clearly not OK to copy any code from the existing driver. Device-specific data such as register offsets are facts, and facts aren't copyrightable, so data contained in the driver can be used. Porting the existing driver implies copying code from it. You could try to understand the existing driver, take notes about how it works, and then try to write a better driver for OpenBSD. Or get realtek to issue a BSD-licensed driver. Or documentation. Nothing beats documentation.
